Decision Archaeology Why Projects Forget Why They Made Decisions
On a long-running capital project, one of the most expensive questions is also one of the simplest: why did we decide that?
The team can usually find out what was decided. A route was selected. A vendor was approved. A coating system was changed. A temporary bypass was accepted. A module was redesigned. A commissioning sequence was reordered. The approval may sit in a minutes pack, a technical query response, a deviation request, or a signed management of change form.
What often goes missing is the reasoning.
Which options were rejected? What assumptions were live at the time? Which constraint mattered most? Was the decision driven by safety, constructability, logistics, schedule, capex, regulatory pressure, interface risk, weather windows, local content, vessel availability, or a late vendor clarification? Who had authority? What evidence was available? What condition was attached to the approval?
That is decision archaeology.
It is the work project teams do when they excavate old records, emails, meeting notes, risk registers, drawings, and memories to reconstruct the context behind earlier decisions. It usually starts when something has gone wrong or become contested. A change request lands. A claim is prepared. A commissioning issue emerges. Operations asks why a maintainability concern was accepted. An assurance reviewer challenges a technical basis. A regulator asks for the history behind a safety-critical choice.
By then, the people who knew the answer may have left. The email trail may be incomplete. The meeting minutes may say “agreed” and little else. The document management system may hold the approved drawing, but not the assumptions that shaped it.
For EPC, infrastructure, energy, mining, marine, utilities, and brownfield projects, this is not just an administrative weakness. It is a commercial, technical, and safety risk.
Why Recording The Final Decision Is Not Enough
Many project systems are built around approvals. They capture the gate decision, the selected option, the signed transmittal, the approved-for-construction revision, or the close-out status. That matters. Projects need clear records of commitments.
But a final decision without context can become dangerously thin.
Consider a brownfield refinery upgrade where the team approved a nonstandard tie-in arrangement during FEED. Two years later, during a shutdown planning review, the construction team asks why the tie-in is located in a congested live plant area rather than a more accessible section of pipe rack. The old decision paper says the arrangement was “approved based on constructability and operations input.” That statement is not enough.
The missing context may include:
The alternative location required an extended production outage.
A corrosion inspection report had flagged access restrictions.
Operations accepted temporary access scaffolding as a condition.
The original decision assumed a 10-day shutdown window.
Vendor nozzle loads had not yet been finalized.
The approval relied on a field survey later found to be incomplete.
Without that context, the current team may reopen the decision, redesign the tie-in, or argue over liability. None of those options is cheap.
Good project governance has long recognized the value of traceability. PMI’s project management guidance emphasizes integration, change control, lessons learned, and knowledge transfer. APM guidance treats decision-making, governance, and information management as core project capabilities. ISO 9001 focuses on documented information and change control. ISO 21502 addresses project governance, knowledge, and information management. ISO 19650 provides widely used principles for managing information across the asset life cycle in built environment projects.
The common theme is clear: decisions need to be traceable, not merely recorded.
For complex capital projects, a useful decision record should preserve at least seven things:
Decision element | Why it matters later |
The decision made | Confirms the commitment or approved direction |
The rationale | Explains why the choice was made |
The evidence used | Shows what information supported the decision |
The assumptions | Identifies what may no longer be true |
The alternatives considered | Prevents repeated rework and circular debate |
The authority | Confirms who had the mandate to decide |
The conditions at the time | Protects against judging old decisions with new facts |
This is especially important because capital projects change shape as they move through the life cycle. A decision made during concept selection may still affect commissioning, start-up, and operations years later. If only the final answer survives, later teams inherit a conclusion without the logic that made it reasonable.
How Decision Context Disappears Across The Project Life Cycle
Decision archaeology rarely results from one failure. It usually grows from many small context losses across phases, companies, systems, and contracts.
Concept And Feasibility
Early project phases create some of the most influential decisions with the least mature information. Assumptions about site selection, technology choice, contracting strategy, plot plan philosophy, logistics routes, utility demand, product slate, marine access, and initial risk allocation can shape decisions that later harden into the project baseline.
At concept stage, decisions often live in economic models, option-selection reports, screening workshops, or sponsor presentations. These records can be persuasive but thin. They may summarize the preferred option without capturing the trade-offs that led there.
For example, an infrastructure project may select a bridge alignment partly to avoid future land acquisition risk. Years later, engineering teams may challenge the alignment on geotechnical grounds. If the original land, permitting, and stakeholder constraints are not captured, the project may waste months revisiting options already tested against a different risk set.
FEED And Definition
FEED is where assumptions start to look like design facts. Battery limits are defined. Equipment philosophies are selected. Layouts are fixed enough to drive estimates. Long-lead items are identified. Contracting packages take shape.
This phase is also a common point where decision context is lost. FEED contractors, owner teams, licensors, specialist consultants, estimators, and operations representatives all contribute. Correspondence may be spread across email, shared drives, document control systems, model review platforms, risk workshops, and value engineering logs.
AACE International’s recommended practices and cost engineering guidance strongly emphasize the basis of estimate, scope definition, risk, and change management. This matters here because a decision without a basis can distort both cost and schedule control. If the estimate assumed stick-built construction and the execution team later shifts to modularization, the record must show whether that was a scope change, an execution strategy change, a productivity assumption change, or a response to site constraints.
Detailed Engineering And Procurement
During detailed engineering, decisions multiply. Material substitutions, vendor deviations, design queries, interface resolutions, equipment layouts, cable routing changes, corrosion allowances, welding procedures, and inspection requirements all create long tails.
Procurement adds another layer. A technically acceptable vendor offer may carry delivery risk. A cheaper package may require additional site work. A preferred pump selection may depend on energy efficiency, spares philosophy, installed base, local service support, or operator familiarity.
Procurement files often retain the purchase order and technical bid evaluation. They may not retain the discussion that explains why the project accepted a deviation or rejected the technically cleaner option. Later, when a defect appears, or a warranty dispute arises, the surviving record may not show whether the owner knowingly accepted the risk or the issue was missed.
Construction And Shutdown Execution
Construction teams manage field reality. Access is worse than expected. Underground services are found in the wrong place. Temporary works are redesigned. Lift plans change. Permit windows shrink. Weather affects marine spreads. Shutdown scope expands.
Many field decisions happen under pressure. A superintendent, construction manager, engineer, and client representative agree on a practical solution to keep work moving. The decision may be captured in a site instruction, field change notice, redline drawing, or daily report. Sometimes it appears only in a chain of emails, photos, and actions from progress meetings.
Shutdowns are especially vulnerable. A 24-hour delay can carry major production impact. Teams make rapid choices on isolation, workface access, test sequencing, temporary repairs, and reinstatement. If those choices are not recorded with their constraints, later disputes can become arguments over memory rather than evidence.
This is where guidance from regulators, process safety institutions, the Energy Institute, and IOGP becomes relevant. Safety-critical decisions need more than a casual trail. When a project accepts a temporary arrangement, bypass, deviation, or changed testing sequence, the record should show the risk assessment, authority, duration, compensating controls, and close-out requirements.
Commissioning, Start-up, Handover, And Operations
By commissioning, many early decisions become operational facts. Valve access, instrument location, preservation quality, energization sequence, spares availability, software configuration, system boundaries, and maintenance access all affect readiness.
Commissioning teams often discover that design decisions were made for cost or schedule reasons that operations did not fully inherit. A packaged unit may require specialist vendor support during start-up. A utility system may have less turndown than expected. A bypass may have been intended as temporary but never removed. A manual operating step may have been accepted because automation scope was deferred.
If handover packs contain drawings, certificates, test records, and manuals but not the decision context behind known limitations, operations inherit uncertainty. That weakens asset integrity, maintainability, and future modification planning.
RICS, ICE, and other professional institutions have long stressed the value of reliable records in construction, contract administration, and asset handover. The practical point is simple: project close-out should transfer usable knowledge, not just documents.
The Commercial And Technical Cost Of Forgotten Reasoning
When teams lose decision context, the damage tends to show up in predictable places.
Change Control Becomes Slower And Less Reliable
Change control depends on the baseline. If nobody can explain why the baseline exists, every change becomes harder to assess.
A contractor may claim that a revised cable route is a client change. The client may respond that the original route was always provisional. The truth may sit in an early model review action that noted access constraints and deferred the final route pending vendor data. If that action was never linked to the engineering record, the project now faces a costly debate.
Good change control needs three layers:
The current approved scope
The reason the scope was approved
The assumptions that would trigger a valid change if they moved
Without those layers, teams confuse design development with change, correction with change, and late discovery with change.
Claims And Disputes Become Memory Contests
Claims specialists and tribunals care about records. Contemporary evidence carries weight because it predates the dispute. Weak records force parties to rely on witness recollection, reconstructed timelines, and selective correspondence.
Incomplete decision records can affect delay analysis, disruption claims, acceleration arguments, design liability, variation entitlement, and professional negligence disputes. A decision that seemed sensible during execution may appear careless later if the file does not show the information available at the time.
AACE International guidance on forensic schedule analysis and recommended practices around change and claims reinforces the need for clear contemporaneous records. The point is not to create paperwork for its own sake. It preserves the evidence needed to explain cause, effect, responsibility, and timing.
Rework Increases Because Teams Repeat Old Debates
When rationale disappears, teams reopen settled decisions. Engineering studies are repeated. Vendors are asked to revalidate choices. Operations asks the same questions raised during FEED. Assurance boards revisit options rejected years earlier.
Sometimes reopening a decision is necessary. Conditions change. New risks emerge. Better data becomes available. The weakness is not reconsideration. The weakness is doing it blind.
If the earlier decision record shows why an option was rejected, the new team can ask a better question: has the condition that drove rejection changed? That is faster and more rigorous than starting again.
Technical Assurance Loses The Basis Of Judgment
Technical assurance needs traceability. Independent reviewers, HAZOP teams, design authorities, marine warranty surveyors, discipline leads, and asset integrity specialists must understand the basis for design and risk decisions.
Decision context is especially important for deviations from standards or specifications. A deviation may be technically acceptable if the project preserves:
The requirement being deviated from
The reason compliance was not practicable or suitable
The risk assessment
The technical authority approval
The compensating measures
The expiry or review condition
When that record is weak, assurance teams face a difficult choice. They either accept unexplained legacy decisions or force conservative rework. Both can add risk.
Safety, Quality, And Commissioning Suffer From Inherited Ambiguity
Safety and quality failures often stem from unclear boundaries and poor knowledge transfer. Peer-reviewed research on major projects, safety management, and organizational learning has often highlighted fragmented information, weak feedback loops, and lost learning across teams.
In practical project terms, this shows up when construction believes commissioning owns a test constraint, commissioning believes engineering accepted it, engineering believes operations approved it, and operations has no record of the discussion.
Operational readiness suffers when late teams are handed decisions without the “why.” They may not know which limitations are temporary, which are deliberate, and which are residual risks that need management after start-up.
Practical Controls That Preserve Decision Context
The answer is not to bury teams under more forms. Experienced project teams already face enough administrative weight. The better aim is to capture decision context at the point where it naturally occurs, then make it searchable and linked.
Use A Decision Register For Decisions That Matter
A decision register should not collect every minor preference. It should focus on decisions with probable consequences for cost, schedule, safety, quality, interfaces, operability, contracting, claims, or future asset performance.
Good candidates include:
Option selection decisions
Scope freezes and basis changes
Key technical deviations
Vendor selection decisions with accepted exceptions
Constructability choices with field implications
Interface agreements between contractors
Temporary works and shutdown decisions
Commissioning sequence changes
Operational readiness deferrals
Safety-critical risk acceptance decisions
A useful register does not need to be complicated. It needs clear ownership and discipline. Each entry should include the decision, date, owner, authority, rationale, evidence, assumptions, alternatives, linked documents, conditions, and any review trigger.
Create Structured Decision Records For High-Impact Choices
For major decisions, a one-page structured decision record can prevent years of confusion. Keep it short enough that people will use it, but complete enough to survive scrutiny.
A practical format covers:
Field | What to capture |
Decision statement | The exact choice approved |
Business or technical driver | The problem the decision solves |
Options considered | The credible alternatives, not every theoretical idea |
Evidence reviewed | Studies, drawings, risk reviews, estimates, vendor data, site surveys |
Assumptions | The inputs treated as true at the time |
Constraints | Schedule, budget, safety, access, outage, regulatory, logistics, contract limits |
Risk and opportunity | Main consequences of the choice |
Approval authority | The role or body that had decision rights |
Conditions and actions | Follow-up checks, expiry dates, or compensating controls |
Links | References to supporting records |
This is especially useful at gate reviews, major procurement awards, value engineering decisions, technical deviations, and operational readiness deferrals.
Link Correspondence Instead Of Copying Everything
Projects often drown in correspondence while still losing context. The issue is not lack of information. It is poor connection between information.
Email chains, letters, technical queries, RFIs, meeting actions, risk reviews, and model comments should link back to the decision they inform. A document control system or common data environment can support this if metadata is used consistently.
The goal is to avoid the familiar search problem: the decisive explanation sits in an attachment to an email from a person who left the project 18 months ago, under a subject line that no one would guess.
Track Assumptions Like Controlled Project Information
Assumptions deserve more respect than they usually receive. In early phases, assumptions are necessary. In later phases, unmanaged assumptions become hidden risks.
An assumption log should identify the assumption, owner, source, affected deliverables, review date, validation method, and consequence if false. It should connect to the decision register and risk register.
For example, an offshore project may assume a heavy-lift vessel will be available during a specific weather window. That assumption affects module weight, hook-up scope, marine logistics, schedule risk, and cost. If vessel availability changes, the original decision basis changes too.
Strengthen Meeting Records Where Decisions Occur
Many project minutes are poor decision records. They capture attendance, general discussion, and action owners, but not the logic behind the decision.
When a meeting makes or confirms a material decision, the minutes should answer:
What was decided?
Who decided it?
What options were discussed?
What evidence was relied on?
What assumptions were stated?
What objections or dissent were recorded?
What actions or conditions were attached?
This does not require long minutes. It requires discipline. A short decision note is often better than five pages of vague discussion.
Build Handover Around Knowledge, Not Only Deliverables
Phase handover should include decision context. Concept to FEED, FEED to EPC, engineering to construction, construction to commissioning, and project to operations all need structured knowledge transfer.
A strong handover pack highlights:
Critical decisions and their basis
Open assumptions and unresolved risks
Deviations and concessions
Interface agreements
Temporary arrangements
Design margins and known limitations
Operations and maintenance implications
Lessons learned that affect the next phase
CII research has repeatedly emphasized front-end planning, alignment, constructability, and lessons learned as important contributors to project performance. Those practices only work when knowledge moves with the work.
How Project Knowledge Systems Can Help Without Creating A Paperwork Machine
The best knowledge systems make the right behavior easier. They do not ask busy engineers, construction managers, contract administrators, and commissioning leads to feed a separate bureaucracy.
A practical project knowledge system should follow a few principles.
Capture Decisions At Natural Control Points
Do not create a parallel process for everything. Use moments where governance already exists:
Gate reviews
Design reviews
HAZOP and risk workshops
Value engineering reviews
Procurement evaluations
Technical deviation approvals
Change control boards
Schedule risk reviews
Constructability reviews
System completion reviews
Operational readiness reviews
At each point, add structured fields for rationale, assumptions, alternatives, evidence, and decision authority.
Use Metadata That People Can Actually Maintain
Complex taxonomies fail when users do not understand them. Metadata should be simple and useful: phase, discipline, system, asset area, contract package, decision type, risk category, document references, and status.
ISO 19650-style information management thinking is useful here because it promotes structured information requirements and controlled environments across the asset life cycle. The project should define what decision information to capture, when, who should capture it, and in what format.
Make Search Reliable Across Systems
Project information often sits in disconnected tools: document control, email, scheduling software, cost systems, risk tools, 3D model platforms, procurement systems, completion management tools, and operations systems.
Full integration may not be realistic. Searchability is. Teams need a way to retrieve linked decision records by system, discipline, tag, package, date, decision owner, and document reference.
This is where discipline in naming, numbering, and linking pays off. A perfect record that no one can find is only slightly better than no record.
Assign Ownership After The Decision
A decision is not complete when approved. Someone must own any conditions, assumptions, and review triggers.
If a project approves a commissioning deferral because a vendor specialist will attend start-up, someone must track the vendor attendance, visa or access requirements, readiness dates, spares, test procedures, and contingency plan. If the condition fails, the decision needs review.
Keep The Threshold Clear
Not every decision needs a formal record. A sensible threshold prevents overload.
A decision should be captured when it could affect:
Safety or environmental performance
Regulatory compliance
Asset integrity
Design basis
Cost or schedule baseline
Contractual entitlement
Quality or certification
Operability or maintainability
Commissioning or start-up sequence
Interfaces between parties
Future modifications or operations
This threshold keeps the system focused on consequential decisions.
Questions Leaders Should Ask When Nobody Can Explain The Decision
When an important decision can no longer be explained, senior leaders should resist the urge to treat it only as a records problem. It may signal a deeper governance weakness.
Useful questions include:
What exactly was decided, and where is the authoritative record?
If multiple versions of the decision exist, the project may lack a controlled source of truth.
Who had the authority to make the decision at the time?
This matters for technical assurance, contractual entitlement, delegated authority, and risk acceptance.
What evidence was available when the decision was made?
Judge the decision against the information available then, not only against what is known now.
Which assumptions supported the decision?
Identify whether the assumptions remain valid or have quietly expired.
Which alternatives were rejected, and why?
This helps determine whether the project needs a fresh option study or only a targeted review.
Were any conditions attached to the approval?
Many decisions are safe only if follow-up actions are completed.
Did the decision transfer properly between phases or contractors?
A sound FEED decision can become a construction problem if context was lost at EPC award.
Does the issue affect safety, quality, certification, or operations?
If yes, treat it as more than a commercial disagreement.
Could the same loss of context exist elsewhere?
One unexplained decision may be a symptom. Look for repeated gaps in deviations, changes, vendor exceptions, and handover items.
10. What control will prevent recurrence?
Do not stop at reconstructing the story. Fix the system that allowed the story to disappear.
These questions are practical because they connect governance, commercial protection, and delivery performance. They also help avoid blame. The aim is not to punish people for working under pressure. The aim is to stop critical knowledge from evaporating.
The Professional Takeaway
Capital projects are temporary organizations that create long-lived assets. That tension explains much of the problem. The project team disbands, the asset remains, and the consequences of old choices continue.
Recording the final decision is necessary, but it is not sufficient. A project that cannot explain why it made major decisions faces avoidable change disputes, repeated analysis, assurance gaps, rework, commissioning friction, and operational risk.
Decision archaeology will always exist to some degree. Complex projects evolve, people move on, and you can't preserve every conversation. The goal is not perfect memory. The goal is enough traceability that future teams can understand the basis of important choices without rebuilding the past from fragments.
Preserving the reasoning behind project decisions matters as much as recording the decisions themselves, because a decision record's value lies not only in what was approved, but in whether future teams can understand, test, and trust it.
