From Preliminary Technical Study to Technical Acceptance: The Full Engineering Cycle of a Public Investment

Understand how need, feasibility, requirements, design, procurement, execution, commissioning, and technical acceptance connect across the engineering lifecycle of a public investment.

Check it out!

The Preliminary Technical Study (ETP) is the planning document that characterizes a public need, compares ways to address it, and supports the selection of a feasible solution. In an engineering investment, its usefulness continues after approval: the study’s needs and assumptions should be translated into design requirements, contractual obligations, and verifiable delivery criteria. This continuity makes it possible to demonstrate, at technical acceptance, whether the investment delivered the contracted outcome.

The ciclo completo conecta necessidade, levantamentos, alternativas, projeto, orçamento, contratação, execução, fiscalização, comissionamento e transferência para operação. Essas atividades possuem responsáveis e entregáveis distintos. The ETP não substitui o dimensionamento do projeto, assim como uma instalação fisicamente concluída não comprova, sozinha, desempenho, segurança ou prontidão operacional. A conexão entre as etapas depende de informação confiável, decisões registradas e evidências que possam ser recuperadas.

Aceite técnico é a conclusão fundamentada sobre o atendimento dos requisitos aplicáveis. Na contratação pública, essa verificação sustenta os procedimentos de recebimento previstos no regime jurídico e no contrato; não cria um ato informal capaz de substituí-los. The planejamento deve, portanto, estabelecer o que será entregue, como será verificado, quem examinará os resultados e quais pendências impedem o avanço. Quando essas perguntas ficam para o final, a Administração pode receber equipamentos sem conseguir demonstrar que recebeu a capacidade de serviço de que precisava.

How the Preliminary Technical Study connects to the public-investment lifecycle

The starting point is the benefit expected for the public or for the operation of the organization. A public unit may need to reduce outages, expand service capacity, correct unsafe conditions, or adapt a facility. “Buy equipment” describes a possible action; it does not yet explain the problem, the required capacity, or the most appropriate alternative. This distinction determines which data need to be collected before selecting the intervention.

In the engineering lifecycle, each stage transforms an earlier decision into more precise and verifiable information. The need becomes a requirement; the requirement guides design; design defines supplies and services; procurement establishes obligations; execution produces evidence; acceptance verifies delivery. A decision remains useful only if its rationale and consequences survive these transitions.

This perspective integrates with the Capital Projects in Public Works, framework, which organizes investment governance from need to operations. Here, the focus is technical continuity among deliverables: which information passes from one team to another and how to demonstrate that it has been preserved. Detailed preparation of the document is developed in the article on Preliminary Technical Study for Engineering Works and Services.

A sequence of decisions, with feedback loops when evidence changes

The process does not operate as an irreversible conveyor belt. A survey may show that the selected alternative does not fit the site; a review may identify insufficient capacity; a test may reveal an interface that fails to meet a requirement. In these cases, the issue needs to return to the decision owner with an impact assessment rather than being concealed by document approval.

The diagram represents an engineering logic, not a mandatory document sequence for every procurement model. The distribution of design activities before and after bidding depends on the contract. Financial, environmental, asset, and administrative controls also need to proceed in parallel. The team should identify these conditions without confusing physical progress with authorization to operate.

Legal requirement, institutional guidance, and engineering method

Brazilian Law No. 14,133/2021 defines the Preliminary Technical Study and structures procurement planning. IN SEGES No. 58/2022 regulates its preparation within the federal scope specified by the rule and covers the federal voluntary-transfer situations provided in Article 2. Its applicability should not be presumed indiscriminately for every entity, funding source, or regime. There are cases in which preparation is optional or waived and correct legal classification is required. Sources: Law No. 14,133/2021 e IN SEGES No. 58/2022.

Já a matriz de rastreabilidade, os pontos de revisão e o exemplo apresentados a seguir constituem uma organização prática de engenharia. Sua configuração deve ser ajustada ao objeto e incorporada aos instrumentos pertinentes. No se pretende atribuir à lei uma exigência universal de planilha, software, nomenclatura estrangeira ou modelo único de governança.

Define the need and understand existing conditions before selecting the solution

The team begins by describing an observable condition. For a public building experiencing electrical outages, it is important to know frequency, duration, affected loads, peak-demand periods, and consequences for service delivery. Without this basis, the phrase “modernize the infrastructure” may result in a broad purchase that does not address the cause of the problem.

The requesting owner defines the required outcome; the technical team translates it into engineering conditions; operations identify use and maintenance constraints. These perspectives need to be reconciled. The request may call for full continuity while budget and infrastructure allow only critical loads to be prioritized. This divergence should be resolved during planning, with a recorded decision on the required service level.

Purpose-driven surveys

The survey is designed around the questions that need to be answered. In existing facilities, it may include asset inventory, inspection of panels and routes, verification of diagrams, demand measurements, access conditions, and interface assessment. In civil works, investigation may require topography, geotechnical borings, and other specific studies. There is no identical set of tests that solves every investment.

Each piece of information should have a source, date, responsible party, and reliability limit. An old drawing may help prepare the inspection but does not prove that the facility remained unchanged. A short-duration measurement may capture an operating condition without capturing seasonality. An inaccessible area needs to be recorded as a constraint, with an explicit consequence for the next decision.

An existing-condition survey of buildings, installations, and infrastructure is appropriate when available information does not allow quantities, interfaces, or implementation conditions to be established. Its scope should indicate the required accuracy and deliverable format. Requesting only a “site visit and report” leaves undefined what will actually be known at the end.

Separate requirement, assumption, and constraint

Requirement is a condition the solution must meet. Assumption is a hypothesis adopted while certain information remains unconfirmed. Constraint limits alternatives or execution. Treating all three as equivalent creates fragile commitments: an assumed electrical capacity may end up being presented to the market as guaranteed availability.

In the building example, maintaining essential service during the intervention is an operational requirement. Assuming that an existing feeder has spare capacity is an assumption to verify. The inability to shut down during certain hours is a constraint. Each item requires different treatment: a performance criterion, field investigation, or outage-window planning.

The output of this stage should show which data support the selection and which uncertainties remain open. If an uncertainty could reverse the choice of alternative or materially change cost and schedule, it is prudent to investigate it before authorizing progression. A simple note stating “to be confirmed during construction” does not define who bears the consequence or how the procurement will be sized.

Compare alternatives and justify feasibility in the Preliminary Technical Study

The Preliminary Technical Study needs to explain why the recommended alternative addresses the need better than the options examined. Brazil’s Federal Court of Accounts treats the study as preliminary planning: once feasibility is demonstrated, the solution is specified in subsequent documents. This guidance helps prevent an equipment catalog from being presented as an alternatives analysis. Source: TCU Procurement and Contracts Manual — Preliminary Technical Study.

For modernization of a building, alternatives may include refurbishing equipment, replacing subsystems, changing architecture, or implementing the intervention in phases. The scenario of maintaining the current condition may also be examined to make consequences explicit, without presenting it as an acceptable option when safety or compliance prevents it.

Compare complete solutions on the same basis

An alternative is not more economical merely because its main equipment costs less. The comparison needs to consider adaptations, supporting infrastructure, implementation, consumption, maintenance, replacement, and other relevant costs over the selected horizon. The analysis loses consistency when one option includes all these components while another accounts only for acquisition.

The market survey in the Preliminary Technical Study should identify ways to meet the need, not merely obtain three prices for a preselected solution. Supplier consultations can clarify limitations, but the recommendation needs to remain supported by the public authority’s criteria and verifiable information.

Comparison dimension	Engineering question	Useful evidence
Meeting the need	Does the alternative deliver the intended capacity and performance?	Operating scenarios and reference requirements
Implementation	Does it fit the site and can it be implemented under operating conditions?	Surveys, interfaces, and preliminary sequence
Lifecycle cost	Which material expenses arise after purchase?	Assumptions for consumption, maintenance, replacement, and disposal
Operations	Can the team operate and maintain the solution?	Planned resources, competencies, support, and routines
Dependencies	The resultado depende de outras contratações ou autorizações?	Register of interfaces, owners, and deadlines
Uncertainty	The que pode alterar a recomendação?	Sensitivity and investigations still required

The table is a comparison guide, not a universal scoring system. If weights are used, they should reflect justifiable priorities and be established transparently. It makes no sense to offset noncompliance with a mandatory requirement through a high price score. Technical admissibility is verified first; then feasible alternatives are compared.

Record the decision and its conditions

The conclusion needs to allow another team to understand the reasoning. In addition to the selected alternative, it is useful to record rejected options, criteria used, demand assumptions, dependencies, and conditions for further development. This prevents a later review from reviving an alternative already rejected without understanding the constraint that drove the decision.

Sensitivity analysis shows whether the recommendation remains valid under plausible changes. If an option is advantageous only under a certain demand growth rate or energy price, that dependency should be explicit. There is no need to present false precision with many decimal places; what matters is revealing under which conditions the decision remains defensible.

The estudo também pode concluir que faltam dados para contratar a implantação. Nesse caso, a próxima entrega pode ser uma investigação ou um estudo de viabilidade mais aprofundado. The avanço fica condicionado à resolução de perguntas concretas, com responsável e prazo. Isso mantém o investimento orientado ao resultado, em vez de transformar o calendário administrativo em substituto da análise técnica.

Turn the decision into requirements and acceptance criteria

The transition from the Preliminary Technical Study to development requires decomposing the expected outcome into verifiable conditions. “Modern system,” “high availability,” and “complete solution” do not, by themselves, establish an acceptance criterion. The team needs to define performance, operating conditions, limits, interfaces, and a demonstration method compatible with the scope.

A well-formulated requirement identifies the function, the scenario in which it will be required, and the expected outcome. It should also make clear who produces the evidence and who verifies it. This does not mean prematurely defining every construction detail. It means preserving the commitment to the need without turning a supplier choice into an unduly restrictive requirement.

The traceability matrix follows maturity

The matrix associates stable identifiers with requirements and indicates where they are addressed. Initially, some columns may still be under development; before procurement and the corresponding tests, the necessary fields need to be defined. The spreadsheet does not replace the design or test protocol: it makes the relationship among documents traceable.

Need or requirement	Translation into design	Procurement obligation	Verification evidence
Maintain essential loads during loss of the normal source	Defined architecture, capacity, and transfer sequence	Supply, integration, and testing under the specified scenarios	Functional-test record and load behavior
Preserve service during the intervention	Phased sequence and temporary supply where necessary	Authorized windows, contingency, and communication	Work-front release and intervention records
Enable safe maintenance	Access, isolation, and identification incorporated	Installation in accordance with documents and delivery of procedures	Inspection, document verification, and operational demonstration
Deliver reliable information to operations	Asset identifiers and documentation requirements	Defined As-Built, manuals, parameters, and training	Cross-check among field condition, documents, and final asset register

The examples need project-specific values, methods, and conditions. This article does not establish universal autonomy, transfer time, or tolerances. Those parameters result from the need, applicable standards, studies, and the capabilities to be procured.

Treat interfaces as part of the scope

A piece of equipment may comply with its catalog and still fail as part of the integrated system. Electrical infrastructure supplies other systems; automation transmits states and alarms; networks support communications; the operations team needs to interpret the information. Each interface should identify source, destination, function, required data, and the party responsible for integration.

Mapping related and interdependent procurements in the Preliminary Technical Study helps identify deliverables located in another contract. Separate contracts do not eliminate physical dependency. If the solution can only be tested after a network or power supply is delivered, that condition should be incorporated into the schedule and acceptance plan.

Requirements review involves users, designers, operations, and inspection according to their responsibilities. Meeting minutes are not enough when decisions change the scope: the relevant documents need to be updated. At the end, the team should be able to trace a need to its evidence of compliance without depending on the memory of those who participated in the study.

Consolidate design, estimate, and the procurement package

The documents should describe the same project and use compatible versions. A design narrative may specify one capacity while the estimate assumes different equipment; the schedule may ignore an approval stage required by the contract; a drawing may include infrastructure absent from the quantities. Each document may appear complete in isolation, but together they transfer contradictions to the market and to inspection.

Package organization depends on the scope and delivery model. Under integrated contracting, the contractor develops the Basic and Detailed Designs from the basis required for that model; under semi-integrated contracting, the contractor develops the Detailed Design. The chain should preserve the necessary level of definition in each case. These differences do not authorize replacing insufficient engineering with generic responsibility clauses. The legal references are Articles 6 and 46 of Brazilian Law No. 14,133/2021.

Design and Terms of Reference perform different functions

The design technically defines the solution at the level corresponding to its phase. The Terms of Reference organize procurement elements, including execution, management, measurement, and payment. Brazil’s Attorney General’s Office advises that these functions should not be confused with the former association between procurement procedure and document name. In its engineering templates, the Terms of Reference have their own legal-administrative content, coordinated with the design. Source: AGU general guidance for procurement and contract templates.

During review, the team should cross-check drawings, design narratives, specifications, quantities, estimate, and delivery conditions. Checking signatures is not enough. A technical specification for engineering works and services needs to enable competition compatible with the scope and provide a usable reference for verifying bids and execution.

Detailed Design development should preserve the contracted solution and requirements, subject to the possibilities and procedures of the applicable delivery model. When a change becomes necessary, the team records the reason, examines impacts, and routes the decision to the competent authority. Approving a drawing does not, by itself, authorize a change in scope, price, or schedule.

Estimate and schedule should reflect the same maturity

Cost Engineering begins with scope and quantities. The TCU publication on public-works estimating spreadsheets explains the relationship among design, price formation, and physical-financial control. Its quantification principles remain useful; legal and tax references in the 2014 document need to be checked against the current framework before application. An old rule should not automatically be carried into a new procurement.

The estimate needs to make the origin of quantities, cost build-ups, and assumptions identifiable. The difference among conceptual, preliminary, and detailed estimates is linked to the available information and the purpose of the estimate. A consolidated amount does not demonstrate that engineering has sufficient precision for every procurement model.

The schedule, in turn, needs to represent real dependencies: area releases, design, approvals, long-lead procurements, auxiliary works, testing, and training. If the project provides for physical delivery on a certain date but integrated tests can occur only after another contract is completed, that date does not represent operational readiness. Management should make the distinction explicit.

Connect technical risk and contractual allocation

The project risk register tracks uncertainties, causes, consequences, treatments, and owners. The contractual risk-allocation matrix defines how certain risks are distributed between the parties. They are related instruments, but not interchangeable: allocating a risk in the contract does not perform the investigation or preventive action required.

An unknown interference may require a survey before bidding; a dependency on an approval requires an owner and follow-up; a limited operational window requires planning and contingency. Each treatment should produce evidence and update the assessment. The phrase “contractor risk” does not by itself clarify the available data, reference conditions, or consequences of an event.

The TCU presents the risk matrix as an allocation instrument and highlights its mandatory use in the cases defined by law, including integrated and semi-integrated contracting and large-scale works and services. Applicability should be verified for the specific case. Source: Risk Matrix — TCU Procurement and Contracts Manual.

During package review, the team needs to verify whether the planned treatment appears in the estimate, schedule, and corresponding obligations. An identified risk without a funded action or defined owner remains open even if a spreadsheet classifies it as controlled.

Review readiness before taking the package to market

A readiness review examines whether remaining uncertainties are compatible with the decision to be made. As an engineering method, it may produce a list of blockers, conditions, and recommendations. A condition that prevents comparable bids or performance verification should not be treated as a simple editorial open item.

The review should prioritize questions that materially affect the procurement:

• Are the solution and interfaces understandable to someone who did not participate in planning?
• Do quantities and local conditions allow coherent bids to be prepared?
• Are design, implementation, integration, and documentation obligations assigned?
• Are inspection, measurement, and acceptance criteria executable?
• Have the resources and operating conditions necessary for delivery been considered?

The result needs to identify an owner and deadline for each correction. At closure, someone should verify the new version and the coherence of affected documents. The preparatory phase for public works procurement organizes the formal process; technical review demonstrates whether the technical content is coherent.

Preserve requirements through procurement, execution, and inspection

After contract signature, the control baseline includes the contract, the documents incorporated into it, and formally authorized changes. The Preliminary Technical Study preserves the history of the decision but should not be used to invent an obligation that was left out of the procurement. If a need was not translated correctly, the inconsistency must be analyzed by the technical and administrative authorities and treated appropriately.

At the start of execution, an alignment meeting should confirm deliverables, versions, communication channels, approvals, milestones, inspections, and interfaces. This meeting does not informally modify the contract. Its objective is to make explicit how obligations will be executed and evidenced, reducing divergent interpretations among designers, suppliers, contractor, and inspection.

Define responsibilities without transferring public authority

Inspection monitors and verifies contractual compliance; the contractor performs the work and demonstrates conformity; designers are responsible for work within their competence; the contract manager coordinates the actions under their authority. Specialized support provides analyses and evidence but does not automatically assume the public authority’s decision-making powers.

Article 117 of Law No. 14,133/2021 permits third parties to assist and support inspection, subject to explicit limits. Support does not exercise duties exclusive to the inspector and does not eliminate the inspector’s responsibility. This distinction should appear in the consulting scope, reports, and decision workflow, in accordance with public-procurement legislation.

Measure progress with evidence, not only percentages

Progress control needs to distinguish equipment that is purchased, delivered, installed, inspected, and tested. These states represent different maturity levels. Payment follows the agreed criteria; the monitoring dashboard should make visible what still needs to happen for each system to perform its function.

An installed assembly may appear complete in photographs and still depend on adjustments, permanent power, identification, software, or testing. For this reason, the technical report should associate activities with location, reference version, and verification record. The TCU emphasizes the need for effective verification of quantities and execution rather than simple acceptance of the contractor’s measurement. Source: Technical Inspection and Provisional Acceptance — TCU.

Control changes, deviations, and nonconformities

A proposed change and a nonconformity are not the same occurrence. The first proposes changing the baseline; the second identifies noncompliance with the applicable baseline. Both need to be recorded, but they follow different analyses. Calling a defect an “optimization” does not eliminate the obligation to demonstrate compliance.

For each change, it is useful to examine the cause, affected requirement, interfaces, cost and schedule effects, and required authority. For each nonconformity, record location, evidence, violated requirement, containment where necessary, correction, and closure verification. An email saying “resolved” does not replace technical confirmation.

Consequences should be propagated through the documents. Replacing equipment may change protection, loads, space, maintenance, training, and spare parts. If only the main drawing is updated, final documentation will carry incompatible versions. This discipline prevents acceptance from becoming the first attempt to reconstruct what actually happened.

Plan inspections and commissioning before physical completion

Commissioning is prepared from requirements and operating scenarios. Leaving test definition until the final stage reduces the ability to correct problems before they become concealed, energized, or integrated with other stages. The plan should state what will be verified, under which conditions, by whom, and with what record.

The intensity of verification should reflect criticality and complexity. A simple replacement does not require the same procedure as infrastructure with multiple sources, automation, and service-continuity requirements. In both cases, however, the team needs to be able to justify why the evidence is sufficient for the requirement in question.

Distinguish inspection, functional testing, and integrated testing

Inspection verifies observable conditions: identification, installation, accessibility, integrity, and document correspondence. A test measures or demonstrates a defined characteristic. Functional testing verifies a function; integrated testing examines the behavior of systems that depend on one another. Approval of one stage does not automatically prove the others.

Factory tests, when specified and relevant, can identify problems before transport. Site tests verify conditions after installation. Neither should be cited as a generic guarantee of performance: their scope depends on the procedure, tested configuration, and represented conditions. A test using partial simulation needs to state what was not demonstrated.

In the building example, individual operation of an emergency source does not prove continuity of priority loads. The control chain, transfer, supply, alarms, and return to normal condition need to be verified within the defined limits and conditions. The principles discussed in commissioning and system readiness help structure this distinction.

Confirm conditions for safe testing

Before starting, the team confirms that installation is complete within the test scope, procedures are approved, instruments are suitable, personnel are qualified, areas are isolated, authorizations are in place, and contingencies are available. Testing cannot be improvised as a way to discover whether the installation is safe. Safety procedures applicable to the system remain an entry condition.

The team also verifies whether there are open items that invalidate the result. A temporary power supply may not represent the final condition; a different software version may prevent reproducing behavior; a missing load may make capacity assessment inconclusive. In these cases, the record should indicate the limitation and the additional verification required.

A controlled execution can follow this sequence:

1. Confirm the requirement version and approve the corresponding procedure.
2. Verify entry conditions and authorize the test.
3. Record configuration, instruments, participants, and relevant conditions.
4. Execute the sequence and record results, including failures and interruptions.
5. Compare the result with the predefined criterion without adjusting it retrospectively.
6. Treat deviations, repeat the necessary verifications, and consolidate the conclusion.

Preserve results that another team can interpret

A useful report makes clear what was tested and with what result. It should link the asset and requirement to the configuration, method, obtained data, and conclusion. A certificate without equipment identification or a form containing only “compliant” may be insufficient to support the decision.

When a failure occurs, retesting should consider the cause and the systems potentially affected by the correction. Changing logic to resolve an alarm may affect another sequence. The extent of retesting needs to be justified, avoiding both overly narrow approval and indiscriminate repetition of the entire program.

Distinguish technical acceptance, formal receipt, and transfer to operations

Technical acceptance consolidates an engineering conclusion supported by verifications. Formal receipt is performed by the competent officials under the applicable rules. For works and services, provisional receipt verifies technical requirements; final receipt confirms contractual compliance through a detailed instrument. Deadlines and methods depend on regulation or contract. The TCU guidance on final acceptance also emphasizes that acceptance does not eliminate remaining responsibilities.

This distinction avoids two shortcuts: treating the final measurement as proof of complete delivery or treating a consulting opinion as equivalent to the administrative act. Specialized reports support the decision and should state scope, evidence, limits, and open items. Signatures need to correspond to each participant’s authority.

Classify open items by consequence

An open-items list should make it possible to decide what prevents testing, energization, use, acceptance, or document closure. Classification cannot be limited to “urgent” and “not urgent”; it needs to reveal the concrete consequence. Missing circuit identification may have different severity depending on the risk and operation involved.

Open items that compromise safety, mandatory compliance, or an essential requirement cannot be normalized through a generic expression such as “acceptance with reservations.” For items whose later treatment is legally and technically admissible, it is necessary to record the owner, deadline, follow-up condition, and closure evidence. The decision needs to respect the contract and administrative authority.

The record should preserve history. An item does not disappear because it was removed from the latest spreadsheet. It should move from open to corrected and verified, with reference to the evidence. This logic makes it possible to audit the conclusion and identify what was effectively accepted at each milestone.

Verify the handover package against the installed condition

The As-Built design records the executed and validated condition. It is not merely a new cover placed over the original design. Its quality depends on updating during construction and final verification. The operations team needs to be able to identify the represented asset in the field and locate its information.

The pacote final pode reunir desenhos, memoriais atualizados, relatórios de ensaio, registros de não conformidade, manuais, parâmetros, garantias e treinamento, conforme o escopo contratado. The nome “Data Book” não resolve a organização. É necessário índice, identificação, revisão e relação entre documentos e ativos.

For digital systems, handover may also involve licenses, configuration backups, recovery procedures, and secure transfer of relevant credentials. This information should not be indiscriminately exposed in public documentation. Availability should respect the classification and controls defined by the public authority.

Deliver the capability to operate

Transfer requires the responsible team to understand limits, alarms, routines, and response to events. Training may need to combine explanation, demonstration, and supervised exercise. An attendance list proves participation; by itself, it does not demonstrate that the necessary situations were covered.

Assisted operation, when contracted, should have defined duration, responsibilities, and closure criteria. It is not intended to absorb implementation defects indefinitely. It is a stage for monitoring behavior under expected conditions and consolidating the transition.

After entry into use, benefit indicators help evaluate the investment. Contract performance and public benefit are related but not identical: service improvement may also depend on staff, processes, and other organizational resources. Subsequent analysis should consider these dependencies, avoiding attribution to the contractor of outcomes that were outside its responsibility.

Example: electrical modernization of an occupied public building

Consider a hypothetical scenario: an administrative building experiences outages and needs to modernize its electrical distribution without interrupting essential service. The example demonstrates the method; it does not represent a contract performed by A3A and does not establish design parameters.

The organization initially considers replacing all panels. The team identifies that this decision preceded diagnosis. Incident records are incomplete, the one-line diagram is outdated, and there is no consolidated list of priority loads. The first useful step is to define the problem and produce enough information to compare interventions.

From diagnosis to procurement

The survey records equipment condition, loads, routes, and access constraints. Measurements are planned to represent relevant operating regimes. The analysis identifies which assumptions still require confirmation and which activities need to occur before final specification.

The Preliminary Technical Study compares interventions with different scope and sequencing. The recommendation considers safety, capacity, continuity during implementation, maintenance, and cost over the adopted horizon. The selected alternative includes adaptations that would be missing if the scope were described only as panel supply.

In design and procurement, the team makes the architecture, required studies, interfaces, and delivery criteria explicit. The schedule incorporates authorized intervention windows and a test sequence by area. The estimate follows the same breakdown, without hiding temporary infrastructure or final documentation behind vague wording.

From execution to evidence of compliance

During installation, the contractor requests substitution of a component. The analysis verifies capacity, compatibility, space, protection, and impact on documentation. The competent decision and revisions are recorded before the change is incorporated. Inspection monitors compliance with the specified inspection points.

During integrated testing, a specific alarm does not reach the operations station. The individual equipment had been approved, but the interface did not function. The result is recorded as a nonconformity, the cause is investigated, and the correction is verified by repeating the affected tests. The final evidence then demonstrates integrated-system behavior.

The acceptance team examines results, documentation, and open items according to its responsibilities. Operations receives verified diagrams, asset identification, procedures, and planned training. The original need remains recognizable in the delivery: not merely installed panels, but infrastructure that can be verified under the contracted conditions.

The example shows where the lifecycle can break. A sound study loses value if the requirement does not reach the bidding documents; a consistent design loses value if substitutions are uncontrolled; correct installation loses operational value if documentation does not support maintenance. Each transition requires an owner for delivery and another for verification.

How to procure engineering support throughout the lifecycle

The need for specialized support arises when the internal team lacks capacity, time, independence, or specific expertise to produce and verify certain deliverables. Concrete signs include lack of field data, interfaces among disciplines, discrepancies between estimate and design, critical operations during intervention, and difficulty defining reproducible tests.

The scope should begin with the decisions the public authority needs to make. Procuring “complete consulting” without defining phases and deliverables makes it difficult to measure the service and distinguish omission from an expectation that was never contracted. It is more useful to describe which questions will be answered, which documents will be examined, which verifications will be performed, and which conclusions need to be delivered.

Organize deliverables, interfaces, and acceptance criteria

Support workstream	Deliverables to define	Service verification criterion
Assessment and planning	Surveys, alternatives, assumptions, and feasibility assessment	Traceable data and substantiated recommendation
Development and review	Requirements, designs, review records, and coordination	Compliance with scope and resolution of comments
Procurement	Cross-check of documents, quantities, and delivery criteria	Identified contradictions and verified corrections
Execution	Inspection reports, change analysis, and monitoring records	Located evidence and substantiated conclusion
Testing and handover	Procedures, results, open items, and acceptance opinion	Correspondence among requirement, verification, and result

In addition to deliverables, the data provided by the public authority, required access, responsible team, response times, and interfaces with other contractors should be defined. A consultant cannot guarantee a complete survey in areas to which it will not have access; it should state the limitation and the planned treatment for resolving it.

Exclusions also need to be clear. Reviewing a design does not automatically mean assuming authorship; witnessing a test does not mean providing it; verifying documentation does not prove the physical condition of portions that were outside the inspection. Limits should appear in the contract and technical conclusion without weakening the obligation to fully perform the contracted scope.

How A3A Engenharia can support

The journey can be structured around condition and maturity assessment, technical development or guidance, and verification of deliverables. Existing services for Preliminary Technical Studies, design, review, inspection support, commissioning, and technical acceptance materialize these workstreams. The scope depends on the investment phase and identified gaps.

Before bidding, technical review of engineering bidding documents and attachments can examine inconsistencies among scope, design, and delivery criteria. During execution, technical support for inspection provides evidence for control and decision-making. At closeout, technical audit of the Data Book and final documentation helps verify the integrity of the document package.

The choice does not need to concentrate the entire lifecycle in a single contract or provider. It should consider independence, segregation of duties, interfaces, and applicable procurement rules. The objective is to ensure that no critical transition lacks technical competence or verification evidence.

Final considerations

The connection between the Preliminary Technical Study and technical acceptance can be tested with an objective question: for each contracted outcome, is it possible to locate the need that originated it, the requirement that defined it, and the evidence that demonstrated compliance?

When the answer is no, the gap needs to be addressed at the stage where it was identified. Before bidding, this may require reviewing the solution or completing the design. During execution, it may require analyzing a change or correcting a nonconformity. At acceptance, it may prevent a conclusion that the available records do not support.

A public investment becomes more consistent when its decisions remain understandable across teams and phases. The Preliminary Technical Study establishes the rationale; engineering develops and controls delivery; verifications support formal acceptance; operations use the capability actually made available. It is through this continuity that planning becomes a demonstrable outcome.

Technical references

[1] BRAZIL. Law No. 14,133, of April 1, 2021. Brasília, DF: Presidency of the Republic, 2021. Available at: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm. Accessed: Sep. 16, 2026.

[2] BRAZIL. Secretariat of Management. SEGES Normative Instruction No. 58, of August 8, 2022. 2022. Available at: https://www.gov.br/compras/pt-br/acesso-a-informacao/legislacao/instrucoes-normativas/instrucao-normativa-seges-no-58-de-8-de-agosto-de-2022. Accessed: Sep. 16, 2026.

[3] BRAZIL. Federal Court of Accounts. Procurement and contracts: TCU guidance and case law. 4.1. Preliminary Technical Study (ETP). Brasília, DF: TCU. Available at: https://licitacoesecontratos.tcu.gov.br/4-1-estudo-tecnico-preliminar-etp/. Accessed: Sep. 16, 2026.

[4] BRAZIL. Office of the Attorney General. Procurement and contract templates: presentation and general guidance. Brasília, DF: AGU. Available at: https://www.gov.br/agu/pt-br/composicao/cgu/cgu/modelos/licitacoesecontratos/apresentacao-e-orientacoes-gerais. Accessed: Sep. 16, 2026.

[5] BRAZIL. Federal Court of Accounts. Guidance for preparing public-works estimating spreadsheets. Brasília, DF: TCU, 2014. Available at: https://portal.tcu.gov.br/publicacoes-institucionais/cartilha-manual-ou-tutorial/orientacoes-para-elaboracao-de-planilhas-orcamentarias-de-obras-publicas. Accessed: Sep. 16, 2026.

[6] BRAZIL. Federal Court of Accounts. Procurement and contracts: TCU guidance and case law. 6.1.4. Technical inspection and provisional acceptance. Brasília, DF: TCU. Available at: https://licitacoesecontratos.tcu.gov.br/6-1-4-fiscalizacao-tecnica-e-recebimento-provisorio-2/. Accessed: Sep. 16, 2026.

[7] BRAZIL. Federal Court of Accounts. Procurement and contracts: TCU guidance and case law. 6.1.6. Contract management and final acceptance. Brasília, DF: TCU. Available at: https://licitacoesecontratos.tcu.gov.br/6-1-6-gestao-do-contrato-e-recebimento-definitivo-2/. Accessed: Sep. 16, 2026.

[8] BRAZIL. Federal Court of Accounts. Procurement and contracts: TCU guidance and case law. 4.5.5. Risk matrix. Brasília, DF: TCU. Available at: https://licitacoesecontratos.tcu.gov.br/4-5-5-matriz-de-riscos/. Accessed: Sep. 16, 2026.

Frequently asked questions

Does the Preliminary Technical Study need to contain the entire Detailed Design?

No. The Preliminary Technical Study supports the choice and feasibility of the solution. Detailed development belongs to the design stages and the parties responsible under the selected delivery model. The study should identify which investigations and developments are still required.

Is technical acceptance the same as final formal acceptance?

No. The technical conclusion uses inspections, tests, and documents to demonstrate compliance. Final formal acceptance is performed by the competent officials under the applicable legal framework and contract. The technical opinion supports that act.

Can procurement occur without a Preliminary Technical Study?

There are cases in which preparation is optional or waived, such as those provided in Article 14 of IN SEGES No. 58/2022 within its scope of application. The applicable classification and agency rules need to be verified. This does not eliminate the need to adequately define the scope and its delivery conditions.

When should acceptance criteria be defined?

During requirements definition and procurement preparation. The level of detail evolves, but enforceable criteria should be established in the relevant instruments before they are applied. They should not be invented after delivery to change what was contracted.

Who is responsible for inspection when a consultant is engaged?

Public officials retain their statutory responsibilities. Specialized support produces analyses and information within the contracted scope. Engaging third parties does not transfer duties exclusive to the inspector or eliminate the responsibilities established in Article 117 of Law No. 14,133/2021.

Is it sufficient to test each piece of equipment separately?

Only when that covers the applicable requirements. If the outcome depends on interfaces, commands, alarms, or shared power, integrated verifications are required under procedures and conditions defined for the system.

Does the final measurement prove that the investment is ready to operate?

Not necessarily. Measurement addresses contractual verification and payment criteria. Readiness also depends on the relevant tests, treatment of open items, documentation, and conditions required for operation.

Additional technical materials

Related services

• Preliminary Technical Study (ETP) for Engineering Works and Services: Need, Alternatives, and Feasibility
• Engineering Existing-Conditions Survey: Buildings, Installations, and Infrastructure
• Design Review in Engineering Projects: Technical Review, Interfaces, and Project Maturity
• Cost Engineering for Engineering Works and Services: Quantities, Cost Build-Ups, BDI, and Reference Basis
• Technical Review of Bidding Documents and Attachments for Engineering Procurement
• Technical Support for Engineering Works and Contract Inspection: Control, Evidence, and Compliance
• Engineering Commissioning: Planning, Testing, Readiness, and Handover
• Technical Acceptance of Engineering Works and Services: Inspection, Documentation, Open Items, and Acceptance
• Technical Audit of Data Book and Final Engineering Documentation

Core content on this topic

• Capital Projects in Public Works: How to Structure Public Investments from Need to Operations
• Preliminary Technical Study (ETP) for Engineering Works and Services: How to Structure a Technically Viable Procurement
• Market Survey in the Preliminary Technical Study: How to Compare Alternatives Without Improperly Restricting Procurement under Law 14,133
• Related and Interdependent Procurements in the Preliminary Technical Study: How to Map Interfaces and Avoid Incompatible Solutions
• Technical Specification for Engineering Works and Services: How to Define Requirements Without Restricting Competition
• Conceptual, Preliminary, and Detailed Estimates: Differences, Accuracy, and When to Use Each
• Preparatory Phase for Public Works Procurement: Documents, Sequence, and Responsibilities under AGU/MGI
• Complete Guide to Procurement and Contracts for Engineering Works and Services

Related technical content

• As-Built Design in Engineering: How to Prepare It, Documents, and Acceptance Criteria
• Industrial Commissioning: Pre-Commissioning, Start-Up, Cold Testing, and Hot Testing
• Public Works Management: How to Prevent Stoppages, Protect Investment, and Reduce Management Risk
• 7 Maturity Gates for Public Engineering Investments: From Funding Allocation to Delivery
• Technical Handover Framework for Works and Systems: From Completion to Operations
• Contracting Engineering Consulting with Traceability, Governance, and Cost Engineering