Basic Data: The Unglamorous Foundation Every Large Capital Project Depends On

1. Capable Teams Can Still Build on Sand

Across every region and every industrial sector, large capital projects begin with the same quiet premise: that the design will rest on facts that are solid enough to trust. Sponsors assemble capable teams, fund early studies and ask for a clean basis of design. Yet the most expensive failures on large capital projects often start earlier and more quietly than a wrong estimate or a late schedule. They start when the scientific and technical package under the design is incomplete, late or treated as paperwork. When that package is wrong, the design cannot be true. When the design cannot be true, scope stays open. When scope stays open in a tightly coupled project network, execution does not fail gracefully. It cascades.

Large capital projects are entrusted to people who know how to engineer, estimate and govern. Those people rarely set out to design on fiction. The failure mode is subtler. A short basis of design looks tidy. A gate checklist shows “definition in progress.” A contractor is assumed to finish the studies that the owner postponed. A schedule promise to the market compresses the time available for reservoir appraisal, orebody work, plant surveys or process definition. None of these moves feels reckless in the week it is made. Together they leave the design resting on sand.

Research on industrial megaprojects treats Basic Data as one of the precursors that did not change between editions of a long-running programme of work: missing, late or wrong Basic Data sits beside a weak project director and poor shaping as an early condition that later chaos merely reveals. The same body of work also records that success rates for the largest industrial projects improved from under 20 percent in the first years of this century to over 40 percent in the most recent period. That is meaningful progress. It is still far short of what established practices can achieve, and it does not license treating the data package as optional when pressure rises.

A related strand of large-project research emphasises that many factors that later dominate outcome are built into front-end definitional decisions, and that rushing the front end toward portfolio listing or sanction is a recognised path into fire-fighting execution. The lesson for this blog is narrower. Capability in the room does not substitute for evidence the design is allowed to trust. When that evidence is thin, the project is already in trouble, even if every meeting still looks professional.

This comprehensive blog will explore what Basic Data is on large capital projects, why it is not the same thing as front-end loading or shaping, how late or wrong data creates cascading failure, and what owners can do about ownership, gates and a Basic Data protocol. It is written for sponsors, business directors, project directors, project managers, owner representatives, process and discipline leads, estimators, project controls professionals and board members who prepare, review or approve major investment decisions. We will define the package, place it among the three pre-authorization work streams, follow the cascade into execution, examine why packages fail, clarify who must own the work, separate Basic Data from useful but different front-end aids such as PDRI and alignment, set out gate questions that can fail a project for data alone, and close with a practical protocol and pointers to related topics treated in forthcoming ProTrain blogs.

2. What Basic Data Is — and What It Is Not

Basic Data is the body of scientific and technical information that underlies facility design. On a megaproject the package runs to many hundreds of pages. It is not a short basis of design. A compact design summary can be useful for communication; it is not a substitute for the full package the design will consume.

What must be in the package depends on the asset. For petroleum production, reservoir size and character matter even when appraisal is incomplete. For minerals, the orebody is central. For expansions and modernizations, the state of the existing plant often dominates. For processing facilities, process definition is the spine. The work often starts before a project is named, especially when new technology is involved. In that sense Basic Data is not only a project deliverable. It is evidence that may have to be gathered while the opportunity is still only a possibility.

The consequences of error are structural. Late or wrong Basic Data produces a design that cannot be true. A design that cannot be true leaves scope open. Open scope in an engineering-intensive megaproject is not a paperwork inconvenience; it is the start of a cascade in execution. The package therefore needs to be complete and available before the design steps that consume it. Late data degrades front-end loading even when the project team is working hard on definition. Most of these failures are treated as preventable. Speed is the main root, along with unclear ownership and the habit of pushing work — for example hazard and operability studies — onto a future contractor.

Figure 1: Basic Data, a short basis of design, and a FEL package answer different questions.

Three distinctions keep the concept clean. First, Basic Data is evidence the design may trust, not a document milestone that can be ticked while the content is still moving. Second, Basic Data is not front-end loading. Front-end loading is the project team’s core work process before authorization: business case and feasibility, scope closure, advanced definition and the execution plan. Third, Basic Data is not shaping. Shaping is the business stream that decides whether the opportunity should be a project and how value is allocated among claimants. A project can look well defined on a FEL scorecard and still be resting on incomplete data, or on a deal that is still open. Confusing the three is how capable teams build on sand.

3. One of Three Streams — Not FEL, Not Shaping

Almost all of what creates success or failure on industrial megaprojects happens before formal authorization. Three streams have to be accomplished and kept in sync.

The first stream is shaping: the business work that turns an opportunity into a venture and an asset, tests whether there is economic value, and aligns every person or organization that claims part of that value so execution can proceed. The second stream is Basic Data: the technical information under the design. On resource projects it often starts first; with new technology it can start years before the opportunity is named. The third stream is project work — front-end loading — the progressive definition of scope and the plan for execution.

Basic Data and front-end loading are familiar professional processes. Shaping is the orphan. Most industrial companies have not installed it as a work process, which is why failed projects still reach sanction. Giving a “strategic” project a dispensation from stage-gate rules removes the control that keeps the three streams honest. A gate that checks only FEL completeness, while shaping is still open or Basic Data is still late, is not the gate this research describes.

Figure 2: Shaping, Basic Data and FEL must stay synchronized before authorization.

This blog keeps the forward links short on purpose. Shaping the deal — the business stream that allocates value and closes claimants — will be examined in a forthcoming ProTrain blog. Front-end loading as a definition and execution-planning process will likewise be treated in a forthcoming ProTrain blog. Here the point is only structural: Basic Data is one of three streams, not a rename of either of the other two, and not a subset of a scope-definition checklist.

A further adjacency is useful without merging the figures. One research programme frames successful delivery as thinking slowly in planning and then acting fast in delivery, because planning is relatively cheap and safe while delivery is expensive and dangerous. Another programme frames front-end loading as a sequenced owner practice chain before authorization, with schedule-driven shortfalls described as near-assured failure paths. Both oppose rushing into execution without adequate front-end work. Neither turns Basic Data into a slogan. The data package remains a specific technical stream that FEL and “think slow” language can hide if sponsors only ask whether definition looks advanced.

4. How Late or Wrong Basic Data Cascades

A cascading failure starts when one element of a network fails and dependent neighbors fail in turn. Projects are networks. The more integrated the network, the more likely a cascade and the more damaging it is. Cascades start small and stay unnoticed until recovery is impractical. Small projects rarely die this way; they have slack to fix one error. Engineering-intensive megaprojects are less forgiving. Design is cumulative, so an early miss — open scope in FEL-2, bad Basic Data, a cost-reduction exercise that reopens scope — spreads. Once a cascade is running in execution, stopping it means stopping the job, which sponsors almost never accept. Schedule slip is the common amplifier.

Figure 3: A small early fault in Basic Data can spread through a tightly coupled project network.

This is a coupling claim, not a bias claim. It explains why front-end faults show up as chaotic execution rather than as a smoothly executed project with a wrong estimate. The practical implication is to hunt early for the small open item — open data, open deal or open scope — rather than for a single late villain in construction. Warning signs between late front-end work and early execution include an old shaping issue returning at sanction, a partner balking, and Basic Data still moving. Those signs are easy to dismiss as temporary. In a tightly coupled network they are how the cascade begins.

5. Why the Package Fails

Most Basic Data failures are preventable. The main roots are speed, unclear ownership and the decision to treat the package as paperwork that someone else will finish later.

Speed is the dominant pressure. Sponsors who want the asset now treat megaprojects as if they can fill a production gap or hit a market window. That schedule pressure from the outset is one of the seven sponsor mistakes recorded across decades of industrial megaproject research. Any one of those mistakes is usually enough to doom the project. The practices that avoid them are described, in a phrase attributed to a chief executive in that research, as smashingly banal; firms fail because they cannot cooperate internally. Speed is not banal on the calendar. It is banal as a governance failure: everyone knows that compressing the data package saves days of early work and risks years of turbulent execution, and the short-term calendar still wins.

Unclear ownership is the second root. If no named owner function is accountable for the package before design consumes it, the package becomes everyone’s problem and no one’s. Pushing studies onto a future contractor is a common form of the same failure. Deferring hazard and operability work until a lump-sum contractor is selected looks efficient in a bid strategy. It is a decision to design without the evidence the design needs. Contracting preference for wholesale risk transfer usually comes from business leadership or financing banks rather than from project professionals; contractors cannot actually carry megaproject risk, and the contract price behaves as a floor rather than a ceiling. Deferring Basic Data into that arrangement does not transfer the risk. It hides it until execution.

Treating the package as paperwork is the third root. A short basis of design, a filled template or a gate slide that says “data in progress” can create the appearance of readiness while the scientific content is still moving. The antidote is not a thicker template. It is a refusal to proceed when the evidence the next design step will consume is not ready.

The fuller map of sponsor mistakes — keeping the whole value pie, wanting the asset now, working out the deal later, refusing front-end risk money, shaving the estimate without changing scope, making contractors carry the risk, and punishing project managers for overruns — will be examined in a forthcoming ProTrain blog on the seven sponsor mistakes. For this blog, three of those mistakes are enough to explain most Basic Data failures: speed, refusal of early risk money, and the hope that a contractor will finish what the owner postponed.

6. Who Owns the Data — the Owner Team

Basic Data is owner work. Contractors can gather, test and engineer under instruction. They cannot decide, on the owner’s behalf, what evidence the design is allowed to trust when the owner has not named the package, funded it or staffed the functions that know what “complete” means for that asset.

An owner team is integrated when all needed owner functions are on the project team during scope development, and three further conditions hold: members are empowered to decide for their function; there is reasonable people continuity; and members report to the project leader, not only back to functional managers. Without integration, information needed for correct scope is missing, wrong or late. Front-end definition weakens. Late changes then kill results, especially on complex projects. If the business case and objectives are coherent, success or failure depends on the owner team and how well it is led. When that team does its preparation, contractor teams rarely fail.

Figure 4: Basic Data completeness, objective alignment and owner-team integration are three different checks.

Several staffing truths sit beside that definition without replacing it. Operations is the role most often missing. Most megaproject teams are understaffed; skeleton staffing is planning to fail. A weak-matrix arrangement in which functions keep review, rotation and who shows up is not integration for complex megaprojects. The core team should form when a project is reasonably likely, not after it is “sure.” Under scarcity, public IPA guidance still wants core seats in owner hands: operations always, maintenance always, the project manager almost always. Cost engineering can be supplemented by third parties if they arrive in time to use owner systems. A vacancy in construction management or cost engineering is described as worse than an agency or experienced contractor. Those scarcity rules help deploy thin headcount. They do not license leaving the data package without an accountable owner function.

Alignment is a different check again. In Construction Industry Institute terms, alignment is the process of incorporating distinct priorities into one set of project objectives that meet the business needs of the proposed facility. Vertical, horizontal and longitudinal dimensions describe whether executives and specialists, peer groups such as business, project management and operations, and the life cycle from planning through operation hold the same objectives. A team can be aligned on paper and still leave the data package incomplete. Integration asks whether the right owner functions are present, empowered, continuous and reporting to the project leader. Alignment asks whether objectives converge. Basic Data asks whether the scientific package is ready. Passing one does not prove the others.

7. PDRI, Alignment and Other Front-End Aids That Are Not Basic Data

Front-end planning research from the Construction Industry Institute is valuable. It is not a synonym for Basic Data.

Front-end planning is defined there as developing enough strategic information for owners to address risk and commit resources. It is an owner-driven process that must stay tied to business goals. The guide states that alignment requires early involvement of operations, business and project management, and names feasibility, concept and detailed scope as phases. The front-end planning effort is typically identified with 2 to 5 percent of total installed cost, depending on type and complexity. That is a CII effort band. It is not the same claim as the industrial megaproject finding that front-end loading investment is about 3 to 5 percent of capital and 30 to 40 percent of cycle time, with best-FEL projects averaging over four times the net present value per dollar of investment of the rest. Keep the figures separate. Do not average them into one “front-end spend” number.

PDRI, as described on the public Construction Industry Institute page for the pre-project planning tools research, is a scope-definition aid for industrial projects. A lower score means a more defined scope. Owners and contractors can use it. No numeric threshold is stated on that live page, and this blog does not invent one. Scope definition aids help teams see what is still open in the definition package. They do not by themselves certify that the scientific package under the design is complete.

Alignment performance in the same research family is also not a Basic Data score. Sample projects with better-aligned teams during front-end planning performed almost 10 percent better on cost and over 16 percent better on schedule on the public research-summary page. The best-practices guide reports a related table from the same research team contrasting less-than-median and greater-than-median alignment on cost, schedule and change orders, and a separate high-versus-low use cut on cost growth. Those are alignment and front-end-planning use contrasts. They support the case for early owner involvement and clear objectives. They do not replace a Basic Data protocol.

A further owner-side account from a National Academies forum describes one company’s insistence that authorization wait until front-end loading is complete, that owner and operator leadership is not delegable, and that competency renewal sits with the business as well as with the project. That testimony is one company’s forum account, not a sample. It is useful as adjacency: owner accountability does not disappear because a contractor is writing drawings.

The distinction that matters for gatekeepers is simple. PDRI and alignment tools help define scope and converge objectives. Front-end loading invests in definition and the execution plan. Basic Data is the evidence those processes are allowed to consume. Scoring definition while the data are still moving is how a project looks healthy on aids that are not Basic Data.

8. Gates That Can Fail a Project for Data Alone

Governance, in the megaproject sense used here, is a set of basic rules for which projects may proceed and which are denied: fund the best risk-weighted returns; stop projects that will destroy money or reputation. A working process does not rely on honesty. It requires the work, so optimism is squeezed out and misrepresentation becomes difficult. Business sponsors often experience the process as an obstacle to capital. That friction is the point.

Gate questions should include Basic Data explicitly. Into scope development: is there enough Basic Data to start; is the business case robust enough to stand development; is there no unexamined killing shaping issue. At a later gate: is Basic Data for design complete; is shaping closed with stakeholders aligned on value; is the project ready for FEED and execution planning; is the risk profile explicit. At authorization: are shaping, Basic Data and the business case materially unchanged; is the project actually ready to execute. A technical authority high in the firm must be able to stop a poorly prepared project. The FEL-1 exit is described as the least well managed gate; too few projects die once FEL-3 has started. That pattern is exactly how late data and open deals survive into sanction.

Figure 5: Each gate asks a harder Basic Data question — and must be able to say no.

A gate that cannot say no is not governance in this sense, even if it has a steering committee. Strategic dispensation from stage-gates for favoured projects removes the control that keeps the three streams synchronized. Schedule-driven projects with no mitigating factors are described as producing grossly inadequate front-end loading and near-assured failure. Those findings sit beside, rather than replace, the broader front-end literature that links careful front-end work to success and rushing toward sanction to downstream fire-fighting. The shared instruction for this blog is operational: write Basic Data into the gate questions, and give someone with technical authority the power to fail the project when the package is not ready.

9. A Basic Data Protocol

The antidote offered in the industrial megaproject research is a Basic Data protocol: agreed timing, clear ownership and a refusal to proceed without the package. Most of these failures are preventable if the people who can slow the project accept that speed is self-defeating.

A practical protocol for large capital projects can be stated without inventing sector checklists the corpus does not contain.

First, name the package early. Decide, for the asset class, what scientific and technical content the design will consume, and who in the owner organisation is accountable for producing it. Reservoir, orebody, existing-plant condition and process definition are examples of content families, not a universal template. The owner function that knows what “complete” means must be on the team during scope development, empowered and reporting to the project leader.

Second, fund the package as risk money. Sponsors unwilling to spend early definition money as pure risk should not attempt the project. Front-end money is risk capital. Refusing it is one of the seven sponsor mistakes. Separately, the industrial megaproject closing claim for front-end loading investment — about 3 to 5 percent of capital and 30 to 40 percent of cycle time — is a reason to protect the calendar as well as the budget. The Construction Industry Institute’s 2 to 5 percent of total installed cost band for front-end planning effort is a different figure from a different programme. Use each in its own lane.

Third, complete the package before the design steps that consume it. Do not score front-end loading as best practical while the data are still moving. Do not defer hazard and operability work or other critical studies to a future contractor as a way to protect the bid calendar. Do not treat a short basis of design as the package.

Fourth, synchronize with shaping and front-end loading. Early economics are uncertain while Basic Data are incomplete. Closing data, deal and scope together is the discipline; giving strategic projects a dispensation from that discipline is how control is removed.

Fifth, write refusal into the gates. Enough data to start scope; data complete before FEED; data materially unchanged at sanction. A technical authority that can stop the project is part of the protocol, not an escalation for special cases.

Sixth, staff for continuity. Form the core owner team when the project is reasonably likely. Protect people continuity through the data and definition period. Treat missing operations and skeleton staffing as protocol breaches, not as temporary inconveniences.

None of this is glamorous. That is the point. Basic Data is unglamorous because it is foundational. The protocol exists to make the unglamorous work non-negotiable.

10. Closing: Protect the Foundation Before the Tower

Large capital projects fail in execution for many visible reasons. The invisible reason is often earlier: the design was never allowed to rest on evidence that was complete, owned and timed to the work that would consume it. Basic Data is that evidence. It is one of three pre-authorization streams, not a rename of shaping and not a subset of front-end loading. Late or wrong data produce a design that cannot be true, then a cascade that sponsors will not stop. Packages fail through speed, unclear ownership and contractor deferral. Ownership sits with an integrated owner team. PDRI, alignment and front-end planning aids are useful and different. Gates must be able to fail a project for data alone. A Basic Data protocol — timing, ownership and refusal — is how capable teams stop building on sand.

Related topics will be developed in forthcoming ProTrain blogs without repeating this one: shaping the deal as the business stream; front-end loading as definition and execution planning; the seven sponsor mistakes that keep killing industrial megaprojects; and the decision-system failures that turn smart teams into confident backers of thin evidence. Until those pieces appear, the instruction from this blog stands on its own. Protect the unglamorous foundation. Every large capital project depends on it.

References

1. Construction Industry Institute. (1997). Pre-Project Planning Tools: PDRI and Alignment (RT-113 / RS113-1 public key findings). https://www.construction-institute.org/pre-project-planning-tools-pdri-and-alignment
2. Construction Industry Institute. (2006). Front End Planning: Break the Rules, Pay the Price (RT-213 public key findings). https://www.construction-institute.org/front-end-planning-break-the-rules-pay-the-price
3. Construction Industry Institute. (2012). CII Best Practices Guide: Improving Project Performance (version 4.0, 23 February 2012). https://www.sig.org/wp-content/uploads/2023/08/CII_Best_Practices_Guide_Improving_Project_Performance.pdf
4. Flyvbjerg, B., & Gardner, D. (2023). How Big Things Get Done.
5. Merrow, E. W. (2024). Industrial Megaprojects (2nd ed.).
6. Merrow, E. W., & Nandurdikar, N. S. (2018). Leading Complex Projects.
7. Porter, J. B., Jr. (2002). In National Research Council, Proceedings of Government/Industry Forum: The Owner’s Role in Project Management and Preproject Planning. https://www.nationalacademies.org/read/10343/chapter/6
8. Wallace, L. (2025). Managing Resource Deployment in a Constrained Environment. Independent Project Analysis. https://www.ipaglobal.com/news/article/managing-resource-deployment-in-a-constrained-environment/
9. Williams, T., Vo, H., Edkins, A., & Samset, K. (2019). A systematic literature review: The front end of projects. Project Management Institute. https://www.pmi.org/-/media/pmi/documents/public/pdf/kas/112112_a-systematic-literature-review_r4_final.pdf