Estimating the Unknowable

Anyone who has priced digital work knows the uncomfortable truth: most upfront estimates are fiction. We’re often asked to quote on a project before we truly understand the problem, the users, or even the right solution. Traditional project delivery makes this worse by locking scope, cost, and timeline at the start and then treating any change as a failure to be suppressed.

The reality is that scope creep is inevitable and not inherently bad. What’s broken is the process that forces all decisions to be made too early. The fix is not a better estimation formula but a structural change: stop treating a large digital program as one monolithic project. Break it into a sequence of smaller engagements, each scoped and priced only when the previous one is complete.

Why Conventional Scoping Fails

The typical corporate project path follows a familiar pattern:

  1. Management requests a project based on vague goals and few details about deliverables.
  2. A stakeholder committee defines the full scope.
  3. The build team is asked to estimate time and cost for that fixed scope.
  4. Delivery focuses on hitting the original deadline and budget, making scope changes the enemy.
  5. The project ships, and everyone moves on.

This model ignores two facts about digital work. First, digital products offer constant feedback on user behaviour and are comparatively easy to change — unlike physical goods. Second, we rarely know enough at the start to define the right solution. Locking down a specification and a price upfront means stakeholders will nevertheless interpret that spec differently, then discover mid-build that critical elements are wrong.

When changes inevitably appear, the team tries to absorb them into an already-agreed deadline and budget. That usually means cutting corners. And even without changes, estimates for complex collaborative work are notoriously unreliable. Any method promising accurate upfront pricing is impractical in real-world conditions because applying it takes longer than the work it predicts. Estimation ultimately comes down to intuition and experience, which is why blame gets unfairly distributed when forecasts miss.

Phased Engagements Instead of One Big Bet

The alternative is to run ambitious programmes as a series of linked projects, scoped one at a time. Even large, sprawling transformations can be split this way rather than committed to as a single engagement. The common sequence has four stages, each a separate engagement with its own deliverables:

  1. Discovery
  2. Alpha
  3. Minimum viable product
  4. Ongoing iteration and optimization

The key is committing only to the first phase, then using its findings to define and estimate the next. Scope creep stops being a problem to fight — it becomes input for the next phase’s scope. Estimates improve because you’re pricing a smaller piece of work and using real outcomes from the previous phase to ground your judgement.

Stage 1: Discovery

Discovery validates the project before any build commitment. For a small project, that may mean a few meetings; for a large one, it becomes a full workstream. Discovery typically involves user research, competitive analysis, identifying key performance indicators, defining what success looks like, understanding constraints, and collating stakeholder opinions.

The output is a far more informed definition of the project: user needs, business objectives, and what actually needs to be built. Crucially, it confirms whether the project will deliver the required value. That deliverable then lets you define the alpha’s scope with better accuracy and adjust direction based on what you’ve learned.

Stage 2: Alpha

Alpha defines how the digital service will work and validates the user experience, usually through prototyping. On smaller projects this might be design mockups; on larger ones, a functional prototype users can try.

Visualising the service achieves three things:

  • It gives all stakeholders a shared vision — a prototype is much harder to interpret differently than a document.
  • It surfaces overlooked requirements early, when changes are cheaper than later in the build.
  • It lets you test the concept with users before investing in a full build.

If user testing goes poorly, you still have room to adapt before committing to the next phase, without blowing the budget or timeline. The alpha’s output also makes the build far easier to estimate — stakeholders can see exactly what they’re being asked to create.

Stage 3: Minimum Viable Product

This stage builds and launches the first version of the digital service. Referring to it as a minimum viable product rather than “the build” shifts expectations: the launch is not the end of the work. That framing leaves space to push genuinely unanticipated complexity or non-essential requests into post-launch iterations, keeping the initial build on track. Items shelved during development become the groundwork for defining the next phase.

Stage 4: Ongoing Iteration and Optimization

Post-launch work picks up what the MVP deliberately deferred. By that point that backlog is comparatively easy to scope and estimate with decent confidence. Beyond that, the phase includes ongoing monitoring, testing, and refinement to make the service progressively more effective. The level of this effort should be proportional to the service’s complexity and the size of the project investment.

Why This Works

Switching to phased delivery yields four clear advantages:

  • Clearer definition per phase. Each stage is specified by the actual deliverables of the one before it, so direction stays visible and surprises are reduced.
  • More realistic estimates. You’re never pricing a vast, unclear programme with unknown variables. You’re pricing the next stage, grounded in concrete results from the last.
  • Better final services. Concepts are validated and tested with users, and scope can flex between phases so the outcome is the most effective product, not just the originally sketched one.
  • Lower risk for the client. Nothing forces a full upfront commitment. A weak discovery case can be stopped cheaply; a prototype that tests poorly can be corrected before major expense.

This risk profile also makes it easier for a client to appoint an outside supplier. Instead of committing a large budget to an unfamiliar agency, they can start with a discovery engagement to judge competence. If the fit isn’t right, they can take the findings elsewhere without losing much. From the supplier side, this phasing can actually win work: clients are far less anxious about a small first step than a full project commitment, and they feel less need to run competitive tenders when switching remains easy.

No approach will make scoping or pricing effortless, and scope creep will not vanish. But by working one phase at a time and letting each stage inform the next, you stop gambling on a fictional upfront estimate and start running a process that keeps adaptations, budgets, and timelines under control.