Build, Buy, or Extend? An Architecture Decision Framework for Capital Project Intelligence

Executive Summary

Capital project organisations facing the question of where to house their project intelligence have three viable architectural paths: extend the existing financial ERP, build a proprietary platform internally, or procure a purpose-built project intelligence platform. Each path has been chosen successfully by serious organisations. Each has also been chosen badly by serious organisations. The difference is rarely the path itself; it is whether the path was selected against a clear-eyed assessment of the organisation's actual situation.

This paper is a decision framework, not an argument. It does not assume that the platform path is the right answer for every organisation, because it is not. There are genuine circumstances in which extending an existing ERP is the rational choice. There are circumstances, rarer than is often supposed, in which building internally is defensible. The purpose of the framework is to surface the variables that should drive the decision, weight them according to the organisation's strategic context, and produce an answer that the chief executive, the chief information officer, and the audit committee can all defend.

The paper is written for the executive team commissioning the architectural decision — typically a CIO leading the analysis, with sponsorship from the CEO and visibility to the CFO. It assumes the reader has already accepted that the status quo of fragmented spreadsheets and personal databases is not a long-term position. The question is no longer whether to act, but which architectural posture to adopt.

The best architectural decision is rarely the one that is loudest in the vendor presentations or the most fashionable in the industry press. It is the one that fits the actual strategic context of the organisation that has to live with it for the next decade.

The Three Paths Defined

Before evaluation, the three options need to be defined precisely, because each is often described loosely in ways that obscure the real trade-offs.

Path A — Extend the existing ERP

This path means licensing the project costing, estimation, scheduling, and execution modules from the same vendor that supplies the financial ERP, and configuring them against the existing financial chart of accounts and master data. The architectural argument is consolidation: one vendor, one data model, one integration boundary. The licensing model is typically modular — the organisation pays for what it switches on, on top of an existing relationship.

Path B — Build internally

This path means commissioning an internal engineering function to design and develop a proprietary platform that fits the organisation's exact operating model, and maintaining it indefinitely. The architectural argument is fit: nothing in the market matches the organisation's specific requirements, so the only way to obtain a true match is to build one. The financial commitment is open-ended, with the largest costs typically appearing in maintenance and feature evolution rather than in initial build.

Path C — Procure a purpose-built platform

This path means selecting a platform that is purpose-built for capital project intelligence — estimating, budgeting, execution, and asset history in a single governed environment — and integrating it to the financial ERP at a defined boundary. The architectural argument is specialisation: project intelligence is a domain with sufficient depth that a horizontal ERP cannot reasonably address it without distortion, and the cost of internal build is rarely justified for capabilities that exist as products. The licensing model is typically subscription, scaled to portfolio value.

Each path is internally coherent. The question is not which path is theoretically superior, but which path fits the organisation's actual situation. To answer that, the framework evaluates each path against six dimensions that, in our experience, drive long-run outcomes.

The Six Evaluation Dimensions

Architectural decisions tend to fail when they are made on one or two visible dimensions while ignoring the others. The six dimensions below are the ones that most reliably predict whether an architectural choice will hold up over a decade.

Dimension 1 — Architectural fit

Does the path produce a system whose data model genuinely matches the shape of project intelligence, or does it force project data into a shape designed for something else? This is the dimension where ERP extensions most often underperform: the financial schema is built for transaction posting, and project intelligence (estimation libraries, productivity factors, supplier judgement, risk patterns) does not naturally inhabit a transactional schema. Conversely, this is also the dimension where internal builds most often underperform — the build team typically lacks the domain depth to design a model that scales beyond the first generation of users.

Dimension 2 — Time-to-value

How long does it take from decision to operational outcome? ERP extensions typically require nine to eighteen months to configure and roll out, with value emerging only after the configuration matures. Internal builds run two to four years before producing meaningful operational value, and frequently never reach the level of maturity that was promised. Purpose-built platforms typically deliver initial value in three to six months, with value compounding as libraries and history accumulate.

Dimension 3 — Total cost of ownership over ten years

Most TCO analyses underweight the second-order costs — integration maintenance, internal training, vendor management, customisation drift, and the opportunity cost of slower adoption. A proper ten-year TCO for each path includes initial build or configuration cost, ongoing licensing or maintenance, internal labour, the cost of integration to adjacent systems, and the cost of not having capabilities the path cannot deliver. We address each of these in the worked example below.

Dimension 4 — Vendor and IP risk

Each path produces a different risk profile. ERP extensions deepen an existing vendor relationship and increase switching cost. Internal builds eliminate vendor lock-in but introduce key-person risk in the engineering team and create a maintenance liability that does not respect business cycles. Purpose-built platforms introduce a new vendor, with the associated negotiation around data ownership, IP portability, and exit terms — risks that are real but contractually addressable, provided the contract is negotiated with intent.

Dimension 5 — Scalability across business model

Does the path support the organisation's actual business model, including the parts that are not yet at scale? Many organisations choose architectures that fit their current dominant activity (typically contracting) but cannot accommodate adjacent activities (joint venture delivery, asset operations, owner-operator work) that are part of the strategic plan. The cost of choosing an architecture that fits today and not tomorrow is usually paid as a second platform decision three to five years later.

Dimension 6 — Compliance and audit posture

Does the path produce a defensible audit trail across estimation, budget, execution, and asset history — one that will satisfy lender due diligence, JV partner audits, and regulatory regimes without scrambling? This dimension is often deferred during the decision because no immediate compliance event is in view. It tends to surface as a forced retrofit later, at considerably greater cost than if it had been addressed in the architectural choice itself.

How Each Path Performs Against the Dimensions

The honest assessment is that no path dominates across all six dimensions. Each has natural strengths and structural weaknesses. Understanding the pattern is more useful than seeking a single winner.

The pattern that emerges is not that one path is right and the others are wrong. It is that the three paths fit different organisational contexts. The decision is not "which path is best" but "which path fits us."

A Worked Example

Consider a contractor with a USD 200 million annual portfolio, an existing tier-one financial ERP, fifteen to twenty active projects, and a strategic intent to expand into joint venture delivery and asset operations over the next five years. Ten-year TCO across the three paths typically falls into the following ranges:

Two observations are worth making about the table.

First, the licensing line is rarely the dominant cost in any of the three paths. The dominant cost is the operational consequence of how long the path takes to deliver value, and how well the resulting architecture matches the actual shape of the work. A USD 4 million difference in licensing across a decade is a rounding error compared to the operational margin recovered by an architecture that produces visibility two years sooner.

Second, the recoverable margin figure (USD 18 to 25 million over ten years) is not a benefit of "choosing the platform path" — it is the benefit of choosing the path whose architecture matches the work, on a portfolio of this profile. For an organisation with different profile attributes — smaller project portfolio relative to financial complexity, narrower business model, deeper existing vendor relationship — the comparison would resolve differently. The framework is the constant; the answer depends on the inputs.

When Each Path Is Genuinely the Right Answer

The credibility of any decision framework depends on its willingness to identify the conditions under which each option is the rational choice. Here are the cases where, in our honest assessment, each path is the right answer.

When Path A (Extend the ERP) is the right answer

The organisation's project portfolio is small relative to its financial complexity. The project intelligence requirement is genuinely shallow — standard work, repeatable methodology, limited multi-currency or multi-region exposure. The existing ERP vendor has specific domain credibility in the organisation's sector and a track record of project module deployment at comparable organisations. The strategic horizon does not include expansion into adjacent business models. Total project value at risk is low enough that architectural fit imperfection is absorbable.

When Path B (Build internally) is the right answer

The organisation has a sustained, well-funded engineering function with a track record of maintaining domain platforms over multiple years. The architectural requirements are genuinely outside the envelope of available products — not just a matter of preference, but of capability. The organisation has the cultural willingness to treat the platform as a permanent corporate function rather than a project. The opportunity cost of the two-to-four-year build window is acceptable. The IP captured in the platform is itself a strategic asset that justifies the build cost.

When Path C (Purpose-built platform) is the right answer

Project intelligence is central to competitive position. The organisation operates — or intends to operate — across multiple business models that require coherent intelligence (contracting, JV delivery, O&M). The time-to-value gap between three months and three years is itself a strategic variable, not a detail. The organisation prefers vendor risk that is contractually addressable to engineering risk that is operationally permanent. Compliance and audit posture matters enough that intrinsic traceability is preferable to retrofitted reporting.

Where an organisation matches the conditions for Path A or Path B clearly, the framework should respect that. Where the conditions are mixed — and they often are — Path C tends to emerge as the path with the lowest regret profile, because it preserves architectural fit, time-to-value, and compliance posture while addressing the vendor risk through contract structure rather than avoiding it entirely.

Decision Framework

Six questions to apply to your own organisation. Answered honestly, they should produce a clear directional answer in most cases.

If the honest answers point clearly toward one path, the decision is largely made. If they are mixed — as is most often the case — the framework should be applied with weighting that reflects the organisation's specific strategic priorities, ideally with the chief executive, the chief information officer, and the chief financial officer agreeing on the weights before the inputs are scored. Disagreements about weighting are usually disagreements about strategy in disguise, and they are better resolved before the architectural decision than after.

A Note on Vendor Selection Within Path C

For organisations whose framework output points to Path C, the next decision — selecting among purpose-built platforms — deserves its own discipline. The contract terms that matter most are the ones that protect the organisation against the very vendor risk that made Path C feel uncomfortable in the first place.

Specifically: data ownership must be unconditional, with the customer retaining full rights to its libraries, methodology IP, and historical project records. Schema portability must be documented and demonstrable, with export capability at the level required for genuine alternative-vendor evaluation. The cost model must scale with portfolio value rather than with intensity of use, so that the platform becoming central to the organisation does not perversely increase the cost of changing direction later. Exit provisions must be specific enough to be enforceable, not aspirational enough to be theatrical.

QBaticPME3 is built and contracted on these terms. The relevant point is not the vendor — it is that any organisation choosing Path C should require these terms from any vendor it considers. The willingness of the vendor to commit to them contractually, rather than rhetorically, is itself a strong signal of which platforms have been built with institutional users in mind.

About QBaticPME3

QBaticPME3 is an enterprise project management and business intelligence platform engineered for construction, engineering, utilities, and infrastructure. It is architected as an institutional intelligence layer, with native interfaces for estimation, budgeting, execution, and maintenance built directly against it. The platform supports three engagement models: equity and joint venture delivery, contracting and quantity surveying, and operations and maintenance. Data sovereignty, schema portability, and IP ownership are contractual commitments, not implementation details.