Reliable project costing comes from standardising how cost drivers are discovered, not assuming every project has the same cost structure.
Two projects can have the same apparent deliverable and radically different economics.
A consulting engagement may require the same number of reports but a very different level of stakeholder negotiation. Two engineering jobs may produce similar drawings, while one requires complex verification, scarce specialists and extensive rework control. Two software implementations may have the same licence footprint but differ sharply in data quality, integration complexity and adoption effort.
When organisations force such work through one standard estimating template, the estimate may look consistent while the underlying economics are not.
The problem is especially visible in service businesses, where the product is often created through human effort, judgement and a sequence of activities rather than through a stable bill of materials.
The Strategic Context
Project costing sits at the intersection of commercial strategy and operational reality.
Price affects whether the organisation wins the work.
Cost affects whether winning the work creates value.
Quality requirements determine which resources and processes are necessary.
Schedule constraints can increase premium labour, overtime or coordination effort.
Uncertainty creates contingency, learning and rework.
A 2018 master's thesis by Azadi Fırat Kaya examined project costing in a localisation-services company. The evidence is limited to a single service-sector case, but the findings are useful because they expose a general problem: apparently similar projects can require different resource quality, process steps and commercial arrangements.
Participants identified linguist rates, client agreements and the number of required processes as important cost factors. A job requiring translation only had a different cost structure from one requiring editing, quality assurance and proofreading. Client expectations affected which specialists were selected and therefore the cost base.
The strategic insight is not specific to translation.
Cost follows the work system that produces the outcome.
What Leaders Commonly Misread
The first error is to mistake a rate card for a cost model.
Rates are inputs. They do not explain how many hours, activities, specialist roles or iterations the work will require.
The second error is to treat average historical cost as the expected cost of the next project.
Averages work well when the underlying process is stable. They become dangerous when complexity, customer requirements or resource mix vary materially.
The third error is to let the customer's target price determine the estimate.
Commercial pressure may require redesign of the delivery model, but lowering the estimate because the client will not pay more does not lower the actual cost.
The fourth error is to focus only on direct labour.
Coordination, quality assurance, rework, technical review, data preparation, change handling and project management may be substantial cost drivers even when they are less visible.
The fifth error is to treat every non-standard project as a failure of estimating discipline.
Sometimes the real issue is that the organisation has entered work for which it does not yet have a stable production model.
In that situation, the estimate should contain uncertainty rather than conceal it.
Reframing the Issue
The better question is not:
What does this type of project usually cost?
It is:
What causes cost to be created in this specific delivery system?
That moves project costing from template completion to cost-driver modelling.
A robust model should connect:
customer requirement → required activities → resource demand → timing → cost → margin
This makes the estimate explainable.
If cost increases, leadership can identify whether the cause is:
- greater volume;
- higher complexity;
- scarce specialist labour;
- additional quality controls;
- shorter schedule;
- more interfaces;
- uncertainty;
- or changes in customer requirements.
This is more useful than knowing that “the project is 15 per cent over budget”.
Strategic Analysis: Cost Drivers Live in the Operating Model
Customer requirements create process requirements
The Kaya case reports that different clients had different quality expectations and technical agreements, influencing the choice of linguists, editors and quality resources.
The general principle is powerful.
Customer expectations are not merely a sales issue. They determine the operating process.
An engineering customer requiring independent verification creates additional review work. A government client requiring detailed assurance and audit evidence creates governance cost. A healthcare implementation requiring higher data controls may require more specialist effort than a superficially similar commercial deployment.
The project estimate should therefore trace cost back to the service promise.
Process count is often more important than headline volume
Volume is usually easy to measure.
Process complexity is harder.
A project involving 1,000 units with one stable workflow may cost less than 500 units requiring multiple reviews, exceptions and handoffs.
The localisation case explicitly identifies the number of process steps as a direct cost factor.
In other sectors, equivalent drivers include:
- number of design iterations;
- number of system integrations;
- number of approval authorities;
- number of stakeholder groups;
- test cycles;
- variants;
- site interfaces;
- or change-control events.
The cost model should reflect these structural drivers.
Resource quality creates nonlinear economics
Scarce expertise is expensive, but cheap resources can also increase rework, supervision and schedule risk.
Costing therefore cannot be reduced to choosing the lowest hourly rate.
A lower-cost resource may require more hours.
A highly experienced specialist may cost more per hour but solve the problem with fewer iterations.
The relevant unit is not the labour rate. It is the cost of achieving the required outcome at the required quality and risk level.
This is where activity-based thinking becomes useful. Costs are traced to activities and the factors that cause those activities, rather than allocated only through broad averages.
Life-cycle cost matters when the project creates an enduring asset
The Kaya thesis also reviews life-cycle costing as a way to consider development, operation, maintenance and termination costs across the life of an asset or system.
That matters because a low project-delivery cost can create a high operating cost.
A cheap piece of equipment can require expensive maintenance. A quickly built software integration can impose years of manual work. A design decision can lower capital expenditure while increasing energy, support or compliance costs.
Project costing and investment appraisal therefore need an explicit interface.
Related article: Business Cases Are Investment Hypotheses, Not Permission Slips
Decision Framework
A practical costing model can use seven cost-driver groups.
| Driver group | Questions to ask |
|---|---|
| Demand | How much work is actually required? |
| Complexity | How many variants, interfaces, exceptions or unknowns exist? |
| Quality | What verification, review and acceptance activities are required? |
| Resources | Which skills, tools, suppliers and facilities are necessary? |
| Process | How many steps, handoffs and iterations create the deliverable? |
| Timing | Does the schedule create overtime, premium resources or concurrency? |
| Commercial conditions | What changes, approvals, warranties, payment terms or client-specific obligations affect cost? |
The model should then distinguish:
base work
known additional requirements
uncertain work
contingency
commercial margin
Combining uncertainty with margin is particularly dangerous. It makes it difficult to know whether the project is profitable or merely consuming hidden contingency.
From Strategy to Execution
Immediate action
Select several recently completed projects and compare their estimates with actual cost.
Do not stop at the variance.
Identify what actually drove the difference.
Was it labour rate, activity volume, rework, quality, change, delay, interface complexity or poor assumptions?
Medium-term capability building
Build a cost-driver library from completed projects.
For each project type, identify the small number of variables that explain most cost variation.
Connect estimating data with time recording, procurement, quality and change data where practical.
Standardise the architecture of the estimate while allowing project-specific drivers to vary.
Long-term strategic positioning
Use cost intelligence to shape the business model.
If a particular customer segment consistently requires more process steps than pricing recognises, commercial strategy should change.
If certain project types depend on scarce specialists, the organisation may need capability development, automation, partner capacity or a different pricing model.
If non-standard work creates disproportionate estimating error, the business may need a paid discovery phase before committing to a fixed price.
Costing should become a source of strategic learning, not merely budget administration.
Signals to Monitor
Leaders should investigate when:
- projects with the same category show wide unexplained cost variation;
- commercial teams routinely override estimating assumptions to reach a target price;
- low-cost resources correlate with high rework or supervision;
- quality activities are repeatedly added after project approval;
- contingency is consumed early;
- non-standard work is priced using standard productivity assumptions;
- or project margins look strong until shared support and rework costs are allocated.
Questions for the Leadership Team
- Which three variables explain most of the cost variation in our projects?
- Are we pricing customer-specific complexity or absorbing it?
- Which activities create cost but are invisible in our current estimating model?
- Where does cheaper labour increase total cost through rework or delay?
- Which project types require discovery before a credible estimate is possible?
- Are we optimising project cost at the expense of whole-of-life operating cost?
Closing Perspective
A good project estimate is not a prediction produced by a template.
It is a model of how the work will create cost.
The strongest organisations standardise the questions, data and estimating discipline while allowing the economics of each project to reflect its real drivers.
That produces more than better budgets.
It improves pricing, resource planning, customer selection, process design and strategic understanding of where the business actually makes money.