Technical Authority in Major Projects: Who Can Challenge an Engineering Decision?
A major project can survive a late pump delivery, a bad weather month, or a difficult claim. It may not survive a weak engineering decision that nobody felt able to challenge.
People often treat technical authority as a governance label. In real delivery, it is a commercial control. It protects design intent, construction quality, operability, safety, regulatory compliance, and asset life. It also protects capital discipline. A design error found during operations is usually more expensive than the same error found during front-end engineering. A compromised decision can lead to rework, delays, warranty exposure, production loss, litigation, or a permanently underperforming asset.
PMI, APM, ISO 9001, ISO 31000, AACE International, CII, IOGP, the Energy Institute, and engineering institutions all point in the same direction, even if they use different language: complex projects need competent decision rights, risk-based assurance, independent review where consequence justifies it, and clear escalation when technical judgment and delivery pressure collide.
The difficult question is not whether engineering matters. Everyone agrees it does. The difficult question is this: who has the standing to challenge an engineering decision when the project is late, the contract is tight, and the commercial team wants closure?
Technical Authority Is A Decision Right, Not A Job Title
A technical authority is a person or function with recognized competence and delegated authority to set, interpret, approve, or reject technical requirements within a defined domain. In an oil and gas project, that may include process safety, wells, structural integrity, rotating equipment, subsea systems, electrical protection, instrumentation, materials, corrosion, or human factors. In infrastructure, it may include geotechnical design, bridge engineering, rail systems, tunneling, drainage, fire life safety, or systems integration.
The title varies. Owner’s engineer. Chief engineer. Technical assurance manager. Discipline authority. Independent checker. Certifying engineer. Responsible engineer. Verification body. What matters is the same: the authority must be competent, independent enough to speak honestly, and connected enough to affect decisions.
That last point is often missed. A brilliant discipline expert with no access to the decision forum is not a technical authority. They are an advisor hoping to be heard.
Technical authority should answer four practical questions:
Who can approve the technical basis of design?
Who can accept a deviation from codes, standards, specifications, or performance requirements?
Who can stop work or require rework where the technical risk is unacceptable?
Who resolves a deadlock between engineering judgment and project delivery pressure?
If those answers are unclear, the organization has not built a technical authority system. It has built an org chart.
This matters because engineering decisions in major projects are rarely pure engineering decisions. A piping material change may reduce procurement lead time but increase corrosion risk. A change in foundation assumptions may save concrete but increase settlement risk. A relaxed factory acceptance test may protect the schedule but transfer defects to commissioning. A software integration shortcut may avoid a milestone slip but create operational fragility for years.
The formal project controls system may record these as changes, risks, nonconformances, concessions, or technical queries. Actual project performance depends on whether the right people can challenge the decision before the cost is locked in.
ISO 9001 provides a useful baseline. It requires control over design and development, externally provided processes, changes, and nonconforming outputs. ISO 31000 frames risk management as integrated with decision-making, not as a separate register exercise. PMI’s project management guidance recognizes governance, integrated change control, quality management, and risk management as core project disciplines. APM places assurance and governance close to benefits realization and decision quality.
None of that works if technical authority is subordinated to milestone theater.
Where Engineering Decisions Become Contested
Technical disagreements do not appear only at final design review. They arise across the full asset lifecycle, often before the project even calls them disagreements.
Concept Selection And Front-End Loading
The most consequential technical choices often happen before the EPC contractor mobilizes. Site selection, technology choice, design life, availability targets, modularization philosophy, geotechnical strategy, constructability assumptions, brownfield tie-in strategy, and execution contracting model all create technical boundaries.
CII has long emphasized the value of front-end planning for project outcomes. AACE International also treats scope definition and basis of estimate as central to cost reliability. The point is not academic. If the business case assumes a fast-track design using immature site data, later engineering “problems” may be symptoms of an underdefined investment decision.
Weak signals at this stage include:
Basis of design documents that repeat business objectives but do not define engineering limits.
Risk registers that list “ground conditions” or “interfaces” without decision owners.
Value engineering that removes redundancy without quantifying operational consequence.
Schedule logic that assumes regulatory acceptance, vendor data, or third-party approvals will arrive on demand.
Technical authority should challenge optimism here. That does not mean blocking the project. It means making uncertainty visible before the board approves a capital number that cannot absorb reality.
Design Development And Procurement
During FEED and detailed design, technical disputes often involve specifications, vendor exceptions, design margins, standardization, and code compliance. Procurement pressure can be intense. A vendor may offer shorter delivery if the project accepts an exception. A package engineer may approve it. The EPC contractor may frame it as commercially reasonable. The owner may see a recovery opportunity.
Some exceptions are harmless. Others move risk from the vendor to the operator.
For example, accepting a lower-grade material, a different seal system, a reduced test scope, or an alternative control architecture may look small in a procurement register. The real impact may appear in maintainability, reliability, spares strategy, hazardous area compliance, cybersecurity, or process safety. Procurement savings may also disappear once lifecycle cost is considered.
RICS and AACE guidance on cost management both recognize that cost decisions should be tied to scope, risk, change, and value. A low purchase price is not a low-cost decision if it creates rework, claims, downtime, or early replacement.
The technical authority’s role is not to reject every deviation. It is to insist that acceptance criteria are explicit. Who owns the residual risk? Does the change affect safety case commitments, regulatory permits, insurance, warranty, performance guarantees, or operating procedures? Has the operator accepted the change, or has the project accepted it on the operator’s behalf?
Those are as much commercial questions as engineering questions.
Construction, Commissioning, And Handover
Construction brings a different pressure. At site, the project has spent most of the capital but has not yet delivered revenue or service. Delay is visible. Field fixes become attractive. Technical authority can look like obstruction.
This is where weak governance is exposed.
A field change to reroute pipe may solve a clash and create a support problem. A temporary energization plan may help commissioning and weaken isolation discipline. A waived inspection point may protect a turnover system and hide a quality defect. A software bypass may permit startup and normalize an unsafe operating mode.
The Energy Institute and IOGP have both published extensively on process safety leadership, human factors, barriers, and assurance. Their guidance stresses that major accident risk depends on barriers remaining effective, not just on personal safety statistics or schedule progress. The same principle applies outside oil and gas. In tunnels, bridges, rail systems, mines, dams, and power assets, the critical question is whether the engineered barriers still perform as intended.
Project indicators can mislead. Percent complete, earned value, milestone compliance, and punchlist closure may look acceptable while technical debt grows. A project can be “green” on a dashboard and still carry unresolved design concessions, incomplete verification, missing vendor data, unclosed technical queries, or unvalidated operating assumptions.
Experienced teams know the trap. The closer a project gets to startup, the more expensive it becomes to tell the truth.
Operations And Asset Life
Technical authority does not end at handover. It becomes asset integrity, change management, maintenance strategy, inspection planning, and operational risk management.
Many project decisions only reveal their quality in service. Did equipment meet availability targets? Are maintainers exposed to avoidable hazards? Are spares unavailable because procurement accepted a nonstandard package? Does the control system generate nuisance alarms? Are operators compensating for poor ergonomics or incomplete automation? Has corrosion appeared where the design assumed dry service?
ISO 55000 on asset management links asset decisions to value, risk, and lifecycle performance. That principle is central here. Technical disagreements during capital delivery should not be resolved only by asking whether the project can reach mechanical completion. They should also ask whether the owner can safely and economically operate the asset for its intended life.
Why Conventional Project Governance Often Fails
Most major projects have governance structures. They have stage gates, design reviews, risk workshops, change boards, quality plans, and assurance schedules. Yet technical failures still pass through them.
The problem is not always absence of process. Often, it is weak decision behavior inside a process that looks sound.
Governance Can Confuse Review With Assurance
A design review is not assurance if attendees lack independence, time, competence, or authority. A document uploaded to a system is not a decision record. A risk workshop does not control risk if the high-consequence items are averaged into a color matrix.
Independent verification matters because complex projects create conflicts of interest. The EPC contractor may have a cost and schedule incentive to defend its design. The owner’s project team may have a milestone incentive to accept it. Vendors may have a supply incentive to limit scope. Operations may be underrepresented because the asset is not yet in service.
Independent assurance does not mean distrust. It recognizes that incentives shape behavior.
The International Association of Oil and Gas Producers has guidance on independent verification and safety-critical elements in major hazard industries. The UK offshore regime also uses independent verification concepts for safety-critical equipment. In construction, independent checking of structural design is common for higher-consequence works. In aviation, nuclear, rail, and process industries, independent review is embedded because missed defects can be severe.
The lesson for capital projects is simple. The level of independence should match the consequence of the decision.
Stage Gates Can Reward Premature Certainty
Stage-gate governance often pressures teams to present a clean narrative. Scope is mature. Risks are understood. Costs are controlled. Schedule is credible. Interfaces are aligned.
Real projects are messier.
The OECD and World Bank have published guidance on infrastructure governance that emphasizes transparency, appraisal quality, institutional capacity, and risk allocation. These themes matter because weak early assumptions do not vanish. They transfer into contracts, contingencies, claims, and technical compromises.
A stage gate should not ask only whether required documents exist. It should ask whether the evidence is good enough to support the decision. That includes asking what is still unknown, who is carrying the uncertainty, and what decision becomes irreversible after approval.
Contracts Can Push Technical Risk Into The Wrong Place
EPC and design-build contracts often promise single-point responsibility. That can be valuable. It can also create an illusion that technical risk has been transferred cleanly.
Contracts allocate liability. They do not eliminate physics.
If the owner provides poor soil data, unclear performance requirements, late operational input, or conflicting standards, the contractor may price risk, qualify assumptions, or claim later. If the contractor underestimates technical complexity, it may seek concessions, substitutions, or accelerated reviews. If both parties become defensive, technical decisions become claim positioning.
This is where contract administration and technical authority must connect. A technical concession can affect the contract price, schedule entitlement, performance guarantees, liquidated damages, insurance, and future claims. Legal and commercial teams need technical evidence. Engineers need to understand commercial consequences.
A disputed engineering decision should not be forced into a binary choice between “approve” and “delay.” Better options include conditional acceptance, additional testing, temporary deviation with expiry, enhanced inspection, compensating controls, commercial reservation of rights, or escalation to agreed independent determination.
The key is to avoid silent acceptance.
Who Should Be Able To Challenge A Decision
The right to challenge should be broad. The right to accept residual technical risk should be narrow.
Any competent project participant should be able to raise a concern. That includes engineers, inspectors, construction supervisors, commissioning technicians, operators, vendors, regulators, and contractors. Many serious failures followed concerns that were treated as inconvenient noise. Studies of major accidents, including official investigations into the Challenger launch decision, the Columbia accident, the Deepwater Horizon disaster, and industrial process safety events, repeatedly show warning signals, normalization of deviance, communication breakdowns, and schedule or production pressure affecting judgment.
Not every concern is correct. Some are incomplete. Some are late. Some misunderstand the design. That does not justify suppressing them. It justifies a disciplined challenge process.
The authority to overrule or accept should sit with named roles based on domain and consequence. A typical model looks like this:
Decision Type | Who Can Challenge | Who Should Decide |
Minor field adjustment within approved design limits | Field engineer, inspector, construction lead, discipline engineer | Responsible discipline engineer |
Deviation from project specification | Contractor, vendor, owner engineer, quality lead, operations representative | Discipline technical authority with commercial change review |
Change affecting safety-critical elements, code compliance, or permits | Any project or operations participant, verifier, regulator | Senior technical authority, owner accountable executive, independent verifier where required |
Departure from basis of design or performance guarantee | Project controls, engineering, procurement, construction, operations, contractor | Project sponsor with documented technical authority recommendation |
Acceptance of unresolved technical risk at startup | Commissioning, operations, HSE, asset integrity, verifier | Accountable operations leader and senior technical authority, not only the project manager |
This distinction matters. A project manager should have strong decision rights over scope, schedule, cost, resources, interfaces, and delivery strategy. But a project manager should not unilaterally accept a technical risk they are not competent to judge and will not own in operations.
That is not a criticism of project managers. It is a control principle.
PMI and APM both recognize governance as the framework for decision-making and accountability. Engineering institutions stress professional obligations to protect public safety, comply with codes, and act within competence. Regulators expect duty holders to control major risks. The commercial organization can negotiate, prioritize, and fund. It cannot vote away the technical basis of a safe asset.
How To Resolve Technical Disagreements Under Pressure
Major projects cannot escalate every disagreement to a steering committee. They also cannot bury unresolved technical concerns under schedule pressure. The answer is a structured path that is fast, evidence-led, and commercially aware.
Start With The Decision, Not The Dispute
Many technical arguments persist because teams argue positions instead of defining the decision. “The contractor wants approval.” “Operations says no.” “Engineering is being conservative.” “Procurement needs release.”
A better first question is narrower: what decision is required now, and what happens if it is wrong?
A decision record should capture:
The technical issue and affected systems.
The applicable requirements, including codes, standards, contract terms, permits, and basis of design.
The available evidence and gaps.
Options considered and rejected.
Safety, operability, cost, schedule, quality, and contractual impacts.
The residual risk owner.
The approval authority.
Any conditions, expiry dates, inspections, tests, or compensating controls.
This is not bureaucracy. It is protection against selective memory.
Separate Technical Acceptability From Commercial Settlement
A common failure mode is mixing two questions:
Can the proposed solution meet the technical and operational requirements?
Who pays for the cost and delay?
These questions are linked, but they should not be collapsed. If the team debates liability before it understands technical acceptability, evidence becomes ammunition. If it approves a weak technical solution to avoid a claim, it may create a larger claim later.
Commercial teams should be in the room. Contracts matter. Notice provisions, variation procedures, relief events, warranties, performance tests, indemnities, and delay damages can all be affected by technical decisions. But commercial pressure should not decide technical adequacy.
AACE International’s recommended practices on change management, forensic schedule analysis, and cost engineering support this separation in principle. You need a defined technical basis before you can credibly assess cost and schedule entitlement.
Use Independent Verification Where Consequence Justifies It
Independence has a cost. It consumes scarce expert time and can slow decisions. Don't use it as a reflex.
It is justified when decisions affect:
Life safety or major accident barriers.
Structural stability or geotechnical performance.
Regulatory approval or license conditions.
Long-term asset integrity.
Performance guarantees or availability commitments.
Irreversible construction or procurement commitments.
Novel technology or immature design assumptions.
High-value claims or disputes where parties have opposed incentives.
Independent verification can take several forms. A third-party checker may review calculations. A specialist may assess a vendor deviation. A certifying authority may verify safety-critical elements. A peer assist may test constructability. An operator’s asset integrity team may challenge inspection strategy. An external expert may advise a dispute board.
The value is not just technical accuracy. It is confidence that delivery pressure has not distorted the decision.
Escalate Before The Choice Narrows
Escalation often happens too late. By the time senior leaders hear the issue, procurement is committed, concrete is poured, modules are shipped, or startup is days away. The remaining options are ugly.
A good escalation system defines triggers before the project is stressed. Examples include repeated rejection of technical queries, unresolved safety-critical deviations, late design changes that affect the construction sequence, missing vendor data for critical equipment, failure to close independent verification findings, and pressure to waive hold points.
Escalation should not be viewed as disloyalty. It is a project control. If the organization punishes escalation, it will fall silent until failure becomes visible.
Senior leaders should ask direct questions:
What requirement are we changing, and who has authority to change it?
What evidence supports technical acceptance?
What evidence contradicts it?
Who will own the risk after handover?
What is the cost of doing it right now versus correcting it later?
Are we making this decision because it is technically sound or because the milestone is exposed?
If this decision appears in an incident investigation or claim file, will the record be defensible?
These questions cut through presentation polish.
Protect The Dissenting View
Dissent is not always right. But competent dissent is a signal. It tells leaders that uncertainty, ambiguity, or competing objectives exist.
A mature project records dissent without forcing false consensus. The decision authority may still proceed. Commercial reality may require accepting some risk. Engineering is not entitled to unlimited time, cost, or certainty. But the record should show what was considered, why the decision was made, and who accepted the residual risk.
This matters for ethics as well as performance. Licensed engineers and chartered professionals have duties that extend beyond employer preference. Codes of conduct from recognized engineering institutions commonly require engineers to work within competence, protect safety, and act with integrity. Organizations should not put professionals in positions where silence is the price of staying on schedule.
The Commercial Case For Strong Technical Authority
Technical authority is sometimes portrayed as conservative friction. That is a poor reading of project economics.
Strong technical authority can prevent late rework, reduce claims ambiguity, protect startup, preserve performance guarantees, avoid regulatory setbacks, and improve asset reliability. It can also help the business take risks knowingly. The aim is not maximum engineering purity. The aim is disciplined risk acceptance.
A commercially aware technical authority understands that projects face real constraints. Capital is limited. Supply chains fail. Brownfield information is incomplete. Weather windows close. Lenders and public stakeholders expect progress. Contractors need timely answers. A perfect solution delivered too late may destroy value.
But a fast answer that ignores technical consequences can destroy more.
The right balance is not found in slogans. It lies in clear authority, strong evidence, timely escalation, and honest ownership of residual risk.
Practical recommendations follow.
Define technical decision rights before contract award. Include deviation approval, independent review requirements, verification hold points, technical query escalation, and operator acceptance roles in the execution plan and contract interfaces.
Make the basis of design a live control document. Treat changes to design assumptions as controlled decisions, not housekeeping. Link them to cost, schedule, risk, permits, procurement, commissioning, and operations.
Track technical debt visibly. Make unclosed deviations, concessions, waivers, verification findings, temporary fixes, and deferred tests visible to project leadership. They should not sit only in discipline logs.
Give operations real authority before handover. Asset teams should not merely receive the project. They should challenge maintainability, operability, spares, barrier management, alarm philosophy, inspection access, and startup readiness.
Match assurance effort to consequence. Use independent verification where failure consequence, novelty, uncertainty, or incentive conflict is high. Do not waste expert capacity on low-risk approvals.
Separate decision quality from outcome luck. A bad decision can appear successful for years. A good decision can still face external shocks. Review the evidence, reasoning, and authority at the time of decision.
Train leaders to recognize technical weak signals. Repeated “minor” concessions, pressure to waive tests, unresolved interface assumptions, late vendor substitutions, and uncomfortable silence in reviews are not noise. They are early warnings.
The real test comes when the schedule is slipping, and the budget is exposed. That is when the organization reveals whether technical authority is a governance phrase or a working control.
Major projects need people who can say, with evidence, “This decision is not technically acceptable.” They also need leaders who can hear that statement without turning it into a personal or commercial threat.
The best project organizations don't let engineering judgment hide behind process, and they don't let commercial pressure override physics. They make the conflict explicit, decide at the right level, document the risk, and own the consequences.
A weak technical challenge culture saves time on paper. A strong one protects value in the ground, in the plant, and over the asset's operating life.
