The most consequential project decisions are often made while the project still looks cheap to change.
Executives tend to become intensely interested in projects after delivery begins. That is when expenditure accelerates, schedules become visible, suppliers mobilise and delays reach the board.
By then, many of the most important choices are already embedded.
The project may have been framed around the wrong need. Requirements may have hardened before users and operators were meaningfully involved. A preferred solution may have been selected before alternatives were properly explored. Governance may have been designed around organisational convenience rather than project complexity. Risk may have been transferred contractually without becoming more manageable in practice. An optimistic budget may have become the political and commercial baseline against which all later decisions are judged.
Execution can improve many things. It cannot cheaply reverse every strategic error made at the front end.
Andrew Davies's 2019 expert report for the Association for Project Management argues that traditional project management has often concentrated too heavily on downstream control while underestimating the strategic decisions made before substantial resources are committed. The report describes this as the front end of the project.
For senior leaders, the front end should be treated as an investment-design phase, not as paperwork before the "real project" begins.
The Strategic Context
Traditional project control is powerful when the problem is to organise known work. Scope, schedules, budgets, work breakdown structures, risk registers and performance baselines create discipline.
The challenge in a large, complex project is that the most important uncertainty may exist before those controls are meaningful.
What outcome is actually required?
Which needs are essential and which are preferences?
What technical solution should be selected?
How mature is the technology?
Which risks should the owner retain?
How should suppliers be organised?
What operating model will eventually receive the output?
What governance can resolve conflicts across multiple parties?
How much uncertainty should be resolved before commitment?
Davies's report argues that it is cheaper and more effective to spend effort early exploring options, evaluating risk, designing project governance and involving key actors from design, finance, construction and operations before major resources are committed.
This does not mean delaying indefinitely in pursuit of perfect information. It means recognising that early uncertainty is where option value is highest.
What Leaders Commonly Misread
The first misread is equating a detailed plan with a well-defined project.
A project can have thousands of scheduled activities and still be strategically weak. Detail does not compensate for an unclear outcome, immature requirements or a poor delivery model.
The second misread is believing that a business case is primarily a funding document.
A strong business case should expose the logic of the investment: strategic need, alternatives, whole-life consequences, risk, affordability, commercial approach and how the organisation will manage delivery. The 2018 UK Government project-delivery standard requires continuing business justification and expects business cases to be revisited before decision points. The deeper principle is that approval should not convert an uncertain proposition into an unquestionable commitment.
The third misread is locking into a preferred solution too early.
Teams often fall in love with a technical answer before defining the operational problem precisely. Once a solution develops political sponsorship, supplier momentum and sunk cost, alternatives become harder to consider objectively.
The fourth misread is treating project setup as administrative mobilisation.
Governance, ownership, contracting strategy, technical integration and operational involvement are design choices. They determine how the project will behave when conditions become difficult.
Related article: Business Cases Are Investment Hypotheses, Not Permission Slips
Reframing the Issue
The front end is where leaders design the project's ability to learn.
This reframing matters because complex projects cannot eliminate uncertainty before starting. What they can do is avoid converting uncertainty into irreversible commitment too early.
A useful front-end question is therefore:
What must be known now, what can be learned later, and which decisions should remain reversible until better evidence exists?
This changes the sequence of work.
Instead of beginning with a single favoured solution and progressively detailing it, leaders can define the need, test outcome requirements, develop credible options, examine comparable experience, identify major uncertainties, involve operators and then increase commitment as evidence improves.
The objective is not slow decision-making. It is disciplined commitment.
Define the Outcome Before the Specification
Davies highlights the value of dialogue among the sponsor, project manager and end user to clarify what is wanted and how users will benefit. The report also notes that specifying operational outcomes rather than prescribing every technical detail can sometimes allow more innovative solutions.
This is strategically important.
A specification describes what to build. An outcome describes what the system must achieve in use.
For a hypothetical hospital project, "install a new patient-flow platform" is a solution statement. "Reduce avoidable delays between admission, treatment and discharge while maintaining clinical safety" is an operational outcome. The second creates room to test whether technology, process redesign, staffing changes or a combination is required.
For a manufacturing project, "buy a new automated line" is not yet a project need. The real requirement may involve throughput, labour exposure, quality consistency, changeover time or capacity flexibility.
Front-end discipline separates the problem from the favoured answer.
Governance Is Part of Technical Strategy
Davies's report emphasises that project governance defines ownership, accountability and the structures connecting sponsors and contractors.
This becomes more important as complexity rises.
A complex project contains choices that cross technical, commercial and operational boundaries. A design change can affect cost, commissioning, software, training, maintenance and supplier obligations. If decision rights are fragmented, the project can optimise parts while damaging the whole.
The sponsor therefore has a strategic role before delivery: establish who owns the project outcome, how major trade-offs will be made, how user and operator needs enter decisions, what information must reach the governing body and which risks require escalation.
The question is not simply whether a steering committee exists.
It is whether the governance design can resolve the kinds of conflict the project is likely to generate.
Related article: Portfolio Governance Is a Decision-Rights System
The Delivery Strategy Must Match Uncertainty
Contracting is often framed as a procurement decision made after project definition.
In complex work, the commercial model is part of project strategy.
Davies's report contrasts situations where fixed-price approaches can work well with circumstances where uncertainty makes them less appropriate. It also describes targeted flexibility, where different contractual approaches are used for different parts of a complex project depending on how predictable they are.
The strategic principle is broader than any particular contract form:
Do not allocate uncertainty as though writing it into a contract makes it disappear.
If a technology is immature, interfaces are poorly defined or requirements are likely to evolve, aggressive risk transfer can create adversarial behaviour, claims and incentives to protect contractual positions rather than solve system problems.
Where work is mature and repeatable, tighter price and scope commitments may be entirely appropriate.
The front end should therefore segment uncertainty before selecting the delivery model.
Decision Framework
Before authorising major commitment, executives should test six front-end dimensions.
| Dimension | Questions |
|---|---|
| Need | Is the problem or opportunity real, material and strategically relevant? |
| Outcome | What must be true in operations for the project to count as successful? |
| Options | Have credible alternatives, including doing less or doing nothing, been considered? |
| Uncertainty | What is unknown about requirements, technology, interfaces, demand, cost or delivery? |
| Organisation | Does governance, capability and commercial structure match the project's complexity? |
| Transition | Who will operate the result, and are their requirements influencing the design now? |
A weak answer does not always mean stop. It may mean that the next phase should be designed to learn rather than to commit.
This is where decision gates become valuable. A gate should answer whether uncertainty has been reduced enough to justify the next level of investment.
From Strategy to Execution
Immediate action begins by identifying the assumptions currently embedded in the project.
Write them down explicitly:
- expected demand;
- technology maturity;
- cost and schedule basis;
- availability of specialist capability;
- user behaviour;
- supplier performance;
- operational readiness;
- regulatory or stakeholder conditions;
- interface stability.
Then distinguish between assumptions that can be tested cheaply now and those that must be managed later.
Next, involve the people who will live with the output. Operators, maintainers, end users, finance, commercial specialists and technical integrators should influence requirements before design freedom collapses.
In the medium term, design governance around the project's real risk. Ensure the sponsor owns the outcome, not merely the approval process. Define decision rights for major technical and commercial trade-offs. Make the business case a living decision document.
Longer term, keep the front-end logic alive during execution. If evidence invalidates the original case, requirements or delivery strategy, governance must allow the project to adapt rather than defend the baseline for its own sake.
Signals to Monitor
Front-end weakness is often visible when:
- the preferred solution appears in documents before the problem is clearly defined;
- project success is described mainly in time and cost terms;
- users and operators are consulted after key requirements are already fixed;
- the business case contains precise numbers supported by weak assumptions;
- alternative options disappear without a transparent decision trail;
- suppliers are expected to carry risks they cannot practically control;
- governance forums spend more time receiving status than resolving trade-offs;
- operational transition is treated as a late-stage workstream;
- early warning evidence is interpreted as a delivery failure rather than information about the original assumptions.
Questions for the Leadership Team
- What problem are we solving, and how do we know it is the right problem?
- Which assumptions would most damage the investment case if they proved wrong?
- What decisions are we making irreversible before the evidence justifies it?
- How have operators and end users shaped the outcome and requirements?
- Does the commercial strategy reflect different levels of uncertainty across the project?
- What would cause us to redesign or stop the project before full commitment?
- Are we funding delivery, or are we first funding the learning required to make delivery credible?
Closing Perspective
Complex projects do not become complex only after work starts. Their complexity is present in the need, stakeholders, technology, interfaces, governance, operating context and uncertainty from the beginning.
The front end is where leaders still have room to shape those conditions.
Strong execution remains essential. But execution is downstream of strategic project design. The earlier leaders define the real outcome, test assumptions, preserve options, build suitable governance and choose a delivery strategy that matches uncertainty, the more likely the project enters delivery with problems it can actually manage rather than commitments it can only defend.
About EraNorth Insights
EraNorth Insights publishes practical analysis on strategy, projects, operations, transformation and decision intelligence for professional and organisational use. About EraNorth.