Engineering & Product Development Planning Under Uncertainty

Why Engineering Timelines Are Notoriously Unpredictable

Software and hardware engineering share a fundamental challenge: the work involves solving problems that have not been solved before in exactly this context. Unlike manufacturing, where you repeat a known process, engineering work regularly encounters unknowns — an API that does not behave as documented, a performance issue that requires architectural changes, a requirement that conflicts with an existing system. These unknowns make traditional deterministic planning inherently unreliable, a pattern explored in depth in why project plans fail.

The problem compounds through dependencies. When Team A is blocked waiting on Team B's API, and Team B discovers their database schema needs rework, the delay propagates through the entire project plan. A two-week slip in one component becomes a six-week slip at the system level because of cascading dependencies and the time needed to re-coordinate across teams.

Scope creep adds another layer of uncertainty. Requirements evolve as stakeholders see early versions and refine their understanding of what they actually need. Technical debt creates drag — what should be a straightforward feature takes three times longer because it must navigate around architectural compromises made years ago. And yet, when engineering leaders are asked for a delivery date, they are expected to provide a single number.

The result is a pattern familiar to every CTO and VP of Engineering: projects consistently take longer than estimated, deadlines are missed, and teams lose credibility with stakeholders. Not because engineers are bad at estimating, but because the tools and processes they use force them to pretend uncertainty does not exist. Incertive takes a different approach — one grounded in the same Monte Carlo simulation methods that have proven effective in other high-uncertainty domains.

Engineering Planning Scenarios

A Real-World Scenario: Planning a Platform Migration

Consider a mid-size SaaS company planning to migrate their monolithic application to a microservices architecture. The CTO has committed to a 6-month timeline based on the team's initial assessment. Three engineering teams will work in parallel: the core services team extracting business logic into services, the infrastructure team building the new deployment platform, and the integration team ensuring backward compatibility with existing clients.

The uncertainties are significant. The core services team has identified 12 bounded contexts to extract, but they estimate that 3 to 5 of those will have unexpected coupling to other parts of the system — they just do not know which ones yet. The infrastructure team is adopting Kubernetes, which nobody on the team has used in production before. The integration team cannot fully test backward compatibility until the core services are running, creating a sequential dependency.

A traditional plan would take the expected duration for each phase, add them up (accounting for parallelism), and produce a Gantt chart showing completion in 6 months. But the CTO knows from experience that migrations like this rarely finish on time. The question is: how late might it be, and what drives the risk?

With Incertive, the team models each workstream with realistic ranges. Service extraction: 2 to 5 weeks per service, depending on coupling complexity. Infrastructure build: 8 to 14 weeks, depending on the learning curve. Integration testing: 4 to 10 weeks, depending on how many compatibility issues surface. They also model a "discovery risk" factor — the probability that a major unexpected issue adds 4 to 8 weeks of unplanned work.

The simulation runs 10,000 scenarios and reveals that the 6-month target has only a 25% probability of success. The P50 (median) outcome is 8.5 months, and the P80 (80% confidence) is 10 months. Sensitivity analysis shows that the largest driver of timeline risk is not any single team — it is the discovery risk factor and the sequential dependency on integration testing. Learn more about how this analysis works.

Armed with this analysis, the CTO can make informed decisions. They might invest in a two-week spike to reduce discovery risk before committing to the full migration. They might staff the integration team earlier and have them build compatibility test harnesses in parallel with core service extraction. They communicate to stakeholders that the migration will take 8 to 10 months with high confidence, rather than promising 6 months and missing. The plan is honest, defensible, and actionable — which is far more valuable than an optimistic date that erodes trust when missed.

Benefits for Engineering Leaders and CTOs

Frequently Asked Questions

Ship With Confidence, Not Crossed Fingers

Describe your engineering project, model the uncertainties, and see the probability of hitting your delivery targets across 10,000 simulated scenarios. Give stakeholders honest timelines backed by rigorous analysis.