Tendering or contracting a project without a sufficiently mature basic design is one of the most common ways to transfer risks into the execution phase. The problem is that when these risks emerge on site, they are already more expensive: they generate change orders, claims, economic-financial rebalancing, rework, delays, disputes and, in more serious cases, stoppages.<\/p>\n\n\n\n
Therefore, before issuing a tender, requesting proposals or signing a contract, the owner needs to answer an objective question: is the basic design complete enough to support the contracting process?<\/strong><\/p>\n\n\n\n This basic design checklist was structured to support managers, engineering teams, procurement, inspection, legal, facilities, IT, physical security and infrastructure personnel in the minimum technical validation before tendering or contracting a project. It can also serve as a starting point for an engineering technical audit<\/a>, an independent review or an Owner\u2019s Engineering<\/a> engagement.<\/p>\n\n\n\n The basic design is not merely a set of drawings. It is the technical basis that makes it possible to characterize the project, estimate cost, define schedule, compare proposals, assess feasibility, inspect execution and control changes.<\/p>\n\n\n\n IBRAOP Technical Guideline OT-IBR 008\/2020 reinforces that the basic design should bring together drawings, narratives, technical specifications, budget, schedule and other elements necessary and sufficient to accurately characterize the project. It should also establish characteristics, dimensions, specifications, quantities, costs and execution time, avoiding significant changes during detailed design and project execution.<\/p>\n\n\n\n In practice, the checklist helps the owner identify whether the project is ready to go to market or whether it still requires basic design development or review<\/a>, FEL for engineering projects<\/a>, complementary studies, design coordination or budget review.<\/p>\n\n\n\n Use the following items as a validation matrix. The more negative answers there are, the greater the risk that the contracting process is premature.<\/p>\n\n\n\n Before discussing solution, price or schedule, the problem the project must solve needs to be defined. A poorly formulated need often results in unstable scope, changes in direction and proposals that are difficult to compare.<\/p>\n\n\n\n When this stage is still uncertain, it may be more appropriate to begin with a technical feasibility analysis<\/a> or alternatives studies before moving on to contracting.<\/p>\n\n\n\n A reliable basic design depends on actual data from the site, the existing asset and implementation constraints. Without an adequate survey, the design starts to depend on fragile assumptions.<\/p>\n\n\n\n For buildings, technology infrastructure, telecommunications, energy or electronic security projects, the site survey<\/a> is a critical stage for reducing gaps between the design and actual site conditions.<\/p>\n\n\n\n A contractible scope is one that allows different suppliers to understand the same requirements, price the same basis and assume comparable responsibilities. When the scope is generic, the procurement process no longer compares equivalent proposals.<\/p>\n\n\n\n This point is central to avoiding the risks discussed in the article on lowest total price in engineering services<\/a>, especially when price is analyzed without sufficient scope maturity.<\/p>\n\n\n\n The descriptive narrative complements the drawings and explains the adopted solutions, assumptions and justifications. It reduces ambiguity and helps the inspection team correctly interpret what was contracted.<\/p>\n\n\n\n Superficial narratives create divergent interpretations among owner, contractor and inspection team. In critical contracts, review of the narrative should be part of an independent design review<\/a>.<\/p>\n\n\n\n A generic technical specification is one of the main drivers of disputes. It allows suppliers to offer solutions with different levels of performance, quality, durability and integration even when they appear to meet the same scope.<\/p>\n\n\n\n This care is especially important in low-voltage electrical installations<\/a>, structured cabling<\/a>, electronic security design<\/a>, access control design<\/a>, lightning protection system design<\/a>, HVAC and data centers and critical environments<\/a>.<\/p>\n\n\n\n Quantities without traceability reduce the ability to review the budget, compare proposals and discuss change orders. The calculation record is the document that shows how each quantity was obtained.<\/p>\n\n\n\n Brazil\u2019s Federal Court of Accounts (TCU) highlights that the quantities in a project cost estimate are better understood when supported by an adequate calculation record. Without this, the spreadsheet loses transparency and the contract loses an objective basis for control.<\/p>\n\n\n\n The budget should not be merely a summary spreadsheet. It represents the design in financial terms and serves as a reference for assessing feasibility, value for money, measurement, price adjustment and scope changes.<\/p>\n\n\n\n A poorly prepared budget can lead to failed tenders, unfeasible bids, change orders or unfinished projects. Therefore, the reference budget and basic design should be assessed together through a technical audit<\/a> or technical opinion<\/a>, when required.<\/p>\n\n\n\n A project schedule needs to represent the actual execution sequence, not merely distribute percentages over time. It should consider constraints, interfaces, approvals, procurement lead times, testing, commissioning and the critical path.<\/p>\n\n\n\n Weak schedules make measurement, inspection, progress control and change-impact analysis more difficult. In complex projects, this validation should be connected to project management<\/a> from the pre-contract phase onward.<\/p>\n\n\n\n Design coordination is one of the most important stages for preventing field interferences. The problem is that many projects only reveal conflicts once execution is underway.<\/p>\n\n\n\n In multidisciplinary projects, BIM coordination<\/a> can support early conflict detection and technical coordination.<\/p>\n\n\n\n Permits, approvals and professional responsibilities should not be left as generic pending items for after contracting. When these requirements arise during execution, they can stop work fronts or require solution redesign.<\/p>\n\n\n\n This care is particularly relevant for systems subject to specific standards and approvals, such as lightning protection, fire protection, electrical installations, electronic security, telecommunications and critical environments.<\/p>\n\n\n\n A risk matrix makes it possible to identify, allocate and treat uncertainties before contracting. Without it, many risks remain silently embedded in the contract and only become visible when there is delay, additional cost or a dispute over responsibility.<\/p>\n\n\n\n When the design still contains many uncertainties, it may be necessary to mature the scope through Front-End Loading<\/a> or assess the project through technical due diligence<\/a>.<\/p>\n\n\n\n A good basic design should allow suppliers to submit comparable proposals. If each bidder interprets the scope differently, the procurement process may select the lowest price only because one proposal failed to include relevant items.<\/p>\n\n\n\n This is an area where Owner\u2019s Engineering<\/a> helps the owner reduce technical information asymmetry, assess proposals and protect the contracting decision.<\/p>\n\n\n\n The checklist can be used at three different points:<\/p>\n\n\n\n For more complex projects, the recommendation is to turn the checklist into a maturity matrix, assigning a status to each item: met, partially met, not met or not applicable. Critical items should be addressed before contracting.<\/p>\n\n\n\n Some signs indicate that the project should not yet be contracted:<\/p>\n\n\n\n These signs are discussed in more depth in the article Basic design is not a formality: it is the main project risk-control instrument<\/a>.<\/p>\n\n\n\n A basic design checklist does not replace specialized technical analysis. But it helps the owner identify gaps before they become contractual, financial or operational problems.<\/p>\n\n\n\n When the basic design is complete, contracting becomes more predictable: proposals are more comparable, the budget becomes more defensible, the schedule becomes more realistic, the inspection team gains an objective basis and risks can be addressed before execution.<\/p>\n\n\n\n A3A Engenharia supports companies and organizations in basic design development and review<\/a>, technical design audits<\/a>, site surveys, feasibility studies, FEL, risk matrices, proposal analysis and Owner\u2019s Engineering<\/a>. The objective is to ensure that the project goes to market on a solid technical basis, reducing change orders, rework, disputes and stoppages.<\/p>\n\n\n\nWhy is a basic design checklist necessary?<\/h2>\n\n\n\n
Basic design checklist before tendering or contracting<\/h2>\n\n\n\n
1. Is the problem or need clearly defined?<\/h3>\n\n\n\n
\n
2. Are there sufficient surveys and assessments?<\/h3>\n\n\n\n
\n
3. Is the scope defined in a contractible manner?<\/h3>\n\n\n\n
\n
4. Is there a consistent descriptive narrative?<\/h3>\n\n\n\n
\n
5. Are the technical specifications objective and verifiable?<\/h3>\n\n\n\n
\n
6. Do the quantities have calculation records?<\/h3>\n\n\n\n
\n
7. Is the budget detailed and defensible?<\/h3>\n\n\n\n
\n
8. Is the physical-financial schedule executable?<\/h3>\n\n\n\n
\n
9. Have the disciplines been coordinated?<\/h3>\n\n\n\n
\n
10. Have permits, approvals and professional responsibilities been addressed?<\/h3>\n\n\n\n
\n
11. Is there a risk matrix?<\/h3>\n\n\n\n
\n
12. Does the basic design allow proposals to be compared fairly?<\/h3>\n\n\n\n
\n
How to use the checklist in practice<\/h2>\n\n\n\n
\n
Signs that the basic design is not ready yet<\/h2>\n\n\n\n
\n
Conclusion: a checklist does not replace engineering, but it prevents blind decisions<\/h2>\n\n\n\n