Budget Estimation in Project-Based Industries: Managing Known Knowns, Known Unknowns, and Unknown Unknowns

In short, budget estimation is not simply the calculation of quantities multiplied by unit rates.

 

In construction, shipbuilding, offshore platforms, mining, quarrying, marine works, fabrication, and complex industrial projects, budget estimation is a structured attempt to convert uncertainty into control.

 

Every project starts with incomplete information. For example, drawings change. Quantities evolve. Client requirements shift. In addition, material prices fluctuate. Labor productivity varies. Machinery availability changes. Meanwhile, subcontractors reprice. Finally, weather, logistics, geopolitics, and macroeconomic shocks interfere.

 

So the question is not whether uncertainty exists.

 

Instead, the real question is whether the contractor has a system capable of identifying, structuring, pricing, controlling, and continuously updating uncertainty before it becomes financial damage.

 

This is where enterprise-grade budget estimation must move beyond spreadsheets and disconnected planning tools. In other words, it must become an integrated cost engineering process that connects scope, quantity, resources, productivity, procurement, schedule, contracts, site execution, change management, and risk.

 

A practical way to understand budget estimation is to classify all variables into three categories:

 

1. Known Knowns
2. Known Unknowns
3. Unknown Unknowns

 

In practice, this classification applies to any project-based environment. For example: a building, a vessel, an offshore platform, a mine, a quarry, a fabrication yard, an infrastructure corridor, or a ship repair project.

 

1. Known Knowns: The Structured Foundation of the Budget

 

Known knowns are the variables that can be identified, measured, structured, priced, and controlled before execution begins.

 

As a result, they form the deterministic foundation of the budget.

 

Without properly capturing the known knowns, the entire budget becomes fragile. After all, a contractor cannot control what nobody has properly defined.

 

1.1 Scope Structure: Job Types, BoQ Lines, Specifications, and Work Breakdown

 

The first known is the structured description of the work.

 

This includes:

 

• Job types
• BoQ lines
• Specifications
• Drawings
• BIM model elements
• Fabrication packages
• Production activities
• Assembly patterns
• Construction sequences
• Work packages
• Deliverables

 

Contractors usually receive these from multiple sources: Excel BoQs, tender documents, drawings, technical specifications, BIM models, IFC files, client requirements, engineering documents, and contract annexes.

 

However, receiving this information is not enough.

 

The contractor must transform it into a structured, tree-like project budget model. For instance, the team may need to break BoQ lines into sub-lines, child items, packages, or nested job types so they reflect the actual way work will be constructed, produced, fabricated, assembled, installed, tested, or handed over.

 

This is critical.

 

A BoQ prepared by a client does not always match the contractor’s operational reality. For example, a single BoQ line may represent multiple production steps. Similarly, a general specification may hide several cost-driving activities. In addition, the team may need to decompose a BIM object into work packages that align with labor, machinery, materials, subcontractors, procurement, inspections, and schedule logic.

 

Therefore, the first known is not just “scope.”

 

It is structured scope.

 

In short, a contractor must know exactly what it is pricing and how it breaks that scope down. It must also know how it will execute the work and how the work connects to the operational pattern of the company.

 

1.2 Quantities: Extracted, Measured, Compared, and Validated

 

The second known is quantity.

 

In practice, every job type, BoQ line, specification, model component, or work package must have a measurable quantity.

 

Quantities may come from:

 

• Excel BoQs
• 2D drawings
• BIM models
• IFC files
• Manual take-off
• Quantity surveying tools
• Engineering calculations
• Site surveys
• Production measurements
• Design revisions

 

The key is not only to extract quantities, but to cross-check them.

 

For example, the estimator should validate a quantity taken from Excel against drawings. Similarly, the team should check a BIM-derived quantity against the tender BoQ. Then, the team should reconcile a 2D take-off with specification requirements. Finally, the team must identify any mismatch before the budget becomes contractual.

 

This is where many project budgets fail.

 

They assume that the quantity received is correct.

 

But in real projects, BoQ quantities, drawing quantities, and model quantities often differ. Those differences create either risk, opportunity, or future claims.

 

Therefore, the second known is validated quantity per job type, BoQ line, specification, or work package.

 

1.3 Cost Recipes and Productivity Templates: Turning Experience into Budget Logic

 

The third known is the knowledge base.

 

Indeed, a serious contractor does not start every estimate from zero.

 

Instead, the company must maintain a structured library of cost recipes and productivity templates. These should draw on previous projects, lessons learned, actual site performance, yard productivity, field execution, procurement history, subcontractor performance, and machinery utilization.

 

For each generic job type or BoQ category, the organization should know:

 

• What labor specialties are required
• What machinery is required
• What materials are required
• What tools are required
• What subcontracted services may be needed
• What indirect resources are associated with the work
• What productivity rates have been achieved historically
• What waste factors normally apply
• What cost rates were used before
• What risks were observed in previous projects
• What deviations occurred during execution

 

In this way, the company converts experience into reusable cost intelligence.

 

For example, if a certain activity historically required a specific mix of labor, machinery, materials, tools, and supervision, that resource assembly becomes a template. Similarly, if that activity historically produced 1 cubic meter every 2 days under similar conditions, that productivity rate becomes a reference. Finally, if market rates have changed, the team can trigger procurement to refresh the cost of materials, subcontractors, equipment, or services.

 

As a result, this creates a practical estimation chain:

 

Scope → Quantity → Resource Assembly → Productivity Rate → Duration → Cost → Schedule Alignment → Procurement Validation

 

At this point, budgeting becomes real cost engineering.

 

1.4 Resources, Volumes, Rates, and Duration

 

Once the contractor knows the job type and quantity, it can apply the relevant cost recipe.

 

In turn, this creates several additional knowns:

 

• Type of resources required
• Volume of each resource
• Cost rate per resource
• Productivity rate
• Estimated duration
• Early start and early finish
• Resource loading
• Procurement requirement
• Machinery requirement
• Subcontracting requirement

 

This is extremely important because cost and time are connected.

 

After all, a budget is not complete if it only calculates cost.

 

It must also estimate duration.

 

For example, if the project schedule requires faster delivery, the contractor may need to increase labor crews or add shifts. It may also hire more machinery, subcontract part of the work, or accelerate procurement. By contrast, if the schedule allows more time, the contractor may optimize resources differently.

 

This means productivity templates are not static. Instead, teams can adjust them depending on execution strategy.

 

For instance, a contractor can ask:

 

Can we reduce duration by increasing manpower? Conversely, can we reduce cost by extending duration? Also, can we use owned machinery or must we rent? Do we have enough internal capacity? Should we subcontract? Then, will the required resources be available when the project starts? Will market prices change by the time procurement begins?

 

These are not theoretical questions. On the contrary, they directly affect bid competitiveness, profit margin, cash flow, and project risk.

 

1.5 Procurement as a Budget Validation Mechanism

 

However, a realistic budget cannot rely only on old prices.

 

Historical prices are useful, but they must be refreshed.

 

For this reason, procurement workflows must update the prices of materials, subcontractors, equipment rentals, fuel, logistics, spares, consumables, and specialized services.

 

This means estimation and procurement should not be disconnected.

 

When the estimator identifies resource requirements, the system should be able to trigger procurement actions such as:

 

• Supplier quotation requests
• Subcontractor RFQs
• Price comparisons
• Vendor evaluations
• Material database updates
• Framework agreement checks
• Alternative sourcing options
• Market price validation

 

In this way, the system transforms procurement from a post-award activity into a pre-award cost intelligence mechanism.

 

The budget becomes more realistic because it reflects not only past cost, but current and forecasted market conditions.

 

2. Known Unknowns: The Expected Uncertainty of Project Execution

 

By contrast, known unknowns are variables that no one can fully define at the start, but everyone expects to occur.

 

Every experienced contractor knows that projects change.

 

The problem is not that change happens. Rather, the problem starts when nobody captures, prices, approves, documents, and baselines the change properly.

 

2.1 Budgeting Gaps and Operational Feedback

 

First, some unexpected costs come from poor budgeting.

 

These may include:

 

• Missing resource assumptions
• Underestimated productivity loss
• Incorrect material waste factors
• Incomplete indirect costs
• Unplanned access restrictions
• Poorly estimated logistics
• Overlooked site constraints
• Inefficient construction methods
• Coordination delays
• Rework
• Quality failures

 

In other words, these costs are “unknown” during estimation, but their existence is known from experience.

 

A mature contractor must capture these deviations during execution and feed them back into the cost recipe library.

 

This is how estimation improves.

 

As a result, every project should make the next estimate stronger.

 

For example, if actual productivity is lower than estimated, the team must update the productivity template. Likewise, if material waste is higher than expected, it must correct the waste factor. If machinery utilization was inefficient, it must revise the machinery assumptions. Finally, if the estimate understated indirect costs, it must improve future overhead logic.

 

Over time, this creates a continuous learning loop:

 

Estimate → Execute → Capture Actuals → Compare → Analyze Deviations → Improve Templates → Estimate Better Next Time

 

2.2 Client-Driven Schedule Changes

 

Another known unknown is schedule change.

 

For example, clients may accelerate deadlines. They may also delay access or change priorities. In some cases, they suspend work. Other clients compress milestones or require additional shifts. Still others extend decision cycles.

 

Each of these changes affects cost.

 

If the client accelerates delivery, the contractor may need:

 

• More labor
• More shifts
• More machinery
• More supervision
• More subcontractors
• Faster procurement
• Higher logistics costs
• Higher overtime
• Higher risk of quality issues

 

On the other hand, if the client delays the project, the contractor may face:

 

• Idle labor
• Idle machinery
• Extended preliminaries
• Increased overhead
• Site demobilization and remobilization
• Supplier storage costs
• Subcontractor claims
• Cash flow disruption

 

This is a known unknown because no one knows the exact change in advance, but the probability of schedule pressure is always real.

 

Therefore, the contractor must be able to document the impact and provide evidence for claims.

 

A schedule change should not remain an informal discussion. Instead, the team must translate it into resource impact, cost impact, productivity impact, procurement impact, and contract entitlement.

 

2.3 Change Management, Variations, and Scope Evolution

 

Projects are dynamic ecosystems.

 

Changes may occur in:

 

• Job types
• BoQ lines
• Specifications
• Drawings
• BIM models
• Materials
• Equipment
• WBS activities
• Construction methods
• Inspection requirements
• Quality records
• Deliverables
• Contractual milestones

 

This is not an exception. It is normal project reality.

 

The critical issue, then, is whether the team captures changes at the point where they happen.

 

For this reason, a contractor must be able to register new job types, BoQ lines, specifications, WBS activities, site instructions, RFIs, quality records, drawings, and supporting documents directly from site, yard, field, vessel, or production area.

 

Then, the system must route them for approval by the client, consultant, owner, class society, or internal authority.

 

Once the authority approves it, the change must trigger:

 

• Revised quantity
• Revised resource requirements
• Revised cost
• Revised schedule
• Revised procurement requirements
• Revised subcontractor commitments
• Revised payment entitlement
• Revised baseline

 

In short, this is the proper way to control variations.

 

Without a new approved baseline, the project team continues comparing actual performance against an obsolete plan. As a result, that creates false reporting, disputed payments, poor claims, and hidden losses.

 

Versioning is essential.

 

For this reason, the contractor must be able to compare the original baseline with the revised baseline and clearly show:

 

• What changed
• Why it changed
• Who approved it
• Which documents support it
• What cost impact it created
• What schedule impact it created
• What payment entitlement it generated
• What risk was transferred or retained

 

In this way, scope creep becomes visible.

 

It also provides auditable evidence for stakeholders such as owners, consultants, banks, insurers, auditors, and dispute resolution bodies.

 

3. Unknown Unknowns: Events Beyond Practical Forecasting

 

Finally, unknown unknowns are events that no one can reasonably predict during budget estimation.

 

These may include:

 

• Geopolitical shocks
• War or regional instability
• Major supply chain disruption
• Extreme inflation
• Currency collapse
• Sanctions
• Sudden regulatory change
• Pandemic-like disruptions
• Natural disasters
• Major energy price shocks
• Border closures
• Force majeure events
• Severe design redefinition
• Extraordinary client-driven scope transformation

 

These variables are beyond normal estimation logic.

 

Estimators cannot fully price them with accuracy. Instead, contractors can only approach them through risk factors, contingencies, contract clauses, escalation mechanisms, insurance, scenario planning, and continuous monitoring.

 

Even so, the mistake many companies make is pretending these risks do not exist.

 

Instead, the correct approach is to:

 

• Define risk allowances
• Apply contingency logic
• Use escalation clauses where possible
• Maintain alternative suppliers
• Monitor geopolitical and market signals
• Preserve contract evidence
• Protect cash flow
• Maintain scenario-based forecasts
• Update the project baseline when events materially alter execution reality

 

No contractor can eliminate unknown unknowns.

 

However, the contractor can contain their impact with structured data, proper contracts, live cost control, and disciplined change management.

 

Why ProjectVIEW ERP Matters

 

DANAOS designed ProjectVIEW ERP for exactly this problem: to connect budget estimation with project execution reality.

 

By contrast, most systems manage fragments.

 

For example, a planning tool manages activities. An accounting system manages financial entries. Meanwhile, a procurement system manages orders. A document system manages files. Similarly, a BIM tool manages geometry and model data. Finally, a spreadsheet manages assumptions.

 

But complex projects do not fail because one department lacks a tool.

 

They fail because the tools are disconnected.

 

 

As a result, this creates a single operational logic:

 

BoQ defines what must be delivered. WBS defines when it must be delivered. Cost Codes define how the team controls cost. Resources define what is required. Then, procurement validates market prices. Site transactions capture actual execution. Approvals control change. Finally, analytics compare budgeted vs actual performance. AI interprets patterns, deviations, risks, and anomalies.

 

In this way, budget estimation becomes budget control.

 

The Role of AI: From Data Capture to Intelligent Cost Control

 

AI can significantly enhance budget estimation and execution control, but only if the underlying data has a proper structure.

 

After all, AI cannot create reliable intelligence from chaotic spreadsheets, disconnected emails, unstructured PDFs, isolated procurement files, and manually updated schedules.

 

Therefore, the deterministic layer must come first.

 

That means:

 

• Structured BoQ
• Validated quantities
• Linked specifications
• Cost recipes
• Productivity templates
• Resource assemblies
• WBS alignment
• Cost code mapping
• Procurement history
• Supplier quotations
• Subcontractor records
• Actual site transactions
• Change records
• Approved baselines
• Version-controlled documents

 

Once this foundation exists, however, AI becomes powerful.

 

It can help identify:

 

• Budget anomalies
• Unrealistic productivity assumptions
• Missing resources
• Scope inconsistencies
• Quantity deviations
• Price escalation risks
• Procurement delays
• Claims opportunities
• Subcontractor underperformance
• Schedule-cost misalignment
• Repeated causes of overruns
• Early warning indicators
• Risk patterns across projects

 

AI does not replace cost engineering.

 

It amplifies it.

 

 

Conclusion: Estimation Is Not a Pre-Contract Exercise. It Is the Beginning of Cost Control.

 

Budget estimation is not a one-time calculation before tender submission.

 

Instead, it is the first baseline of project control.

 

So a serious budget must define what is known and anticipate what is likely to change. It must also prepare the organization for what no one can predict.

 

Known knowns must be structured, measured, priced, scheduled, and validated. Next, the team must capture, approve, claim, and baseline known unknowns. Unknown unknowns must be risk-managed, monitored, and contractually protected.

 

 

That requires more than spreadsheets.

 

It requires an integrated operating system for project execution.

 

This is the role of ProjectVIEW ERP: to provide the digital backbone where estimation, budgeting, procurement, planning, execution, change management, cost control, and AI-driven intelligence operate as one connected ecosystem.