Uncertainty

Below are some representative, though not exhaustive, examples of uncertainty. Further insights on this topic are available in the dedicated Insights section.

Many projects begin with the assumption that requirements are already defined, while what seems clear at the beginning is often only a simplification of the problem. As the software takes shape, exceptions, edge cases, operational dependencies, and new business needs emerge.

The real domain is understood progressively: the risk begins when this evolution is treated as a mistake rather than as a natural characteristic of software projects.

If change is not managed explicitly, the project quickly enters into conflict: expanding scope, pressured budgets, misaligned expectations, and decisions made too late.

Defining time and cost before truly understanding the problem creates a false sense of control, often leading to decisions made with incomplete information.

The real complexity of a system only emerges when processes, integrations, legacy constraints, data quality, and organizational dependencies are analyzed. Without this phase, initial estimates easily become arbitrary.

When the budget is built on unvalidated assumptions, the risk is simply postponed, later turning into constant revisions, extra requests, technical compromises, or tension between client and supplier.

Many projects must coexist with existing software, legacy integrations, layered databases, and processes built over time.

Documentation is often incomplete, knowledge is concentrated among a few people, and some dependencies only emerge during development. What initially appears to be a simple integration can evolve into a broader architectural problem.

Ignoring this complexity leads to underestimated effort, timelines, and risks, producing a fragile system that is difficult to evolve and forced to adapt to constraints discovered too late.

Every project requires progressive decisions that need to emerge at the right moment. When ownership or decision-making responsibility is unclear, the project slows down: priorities constantly shift, feedback arrives too late, and validations are postponed.

This creates operational ambiguity: the team develops without real confirmation, assumptions accumulate, and corrections arrive when the cost of change is already high.

In software projects, the absence of a decision is often riskier than an imperfect decision.

Some suppliers present highly precise estimates, timelines, and guarantees before the real complexity of the project has even been explored.

This apparent precision often hides assumptions that have not yet been validated: integrations, operational constraints, data quality, organizational dependencies, or evolving requirements.

The risk is building trust around numbers that are structurally fragile. When uncertainty is ignored instead of managed, estimates become promises that the project may not realistically sustain.

Clients often arrive with an already defined idea: “we need an app”, “we need a portal”, “we need to rebuild the ERP”, while a solution rarely coincides with the real problem.

Starting directly from technology or from a functional request creates the risk of ignoring the context that generated the need: inefficient processes, missing integrations, unclear roles, or misaligned objectives may remain invisible.

The risk is building the wrong thing correctly. In software, correcting direction after months of development is far more expensive than clarifying the problem at the beginning.

In complex projects, software depends on multiple working groups: different departments, stakeholders with conflicting priorities, external suppliers, and systems managed by other teams.

Every dependency adds variability: a blocked decision, an unavailable API, or delayed information can slow down the entire project.

When responsibilities are distributed but not clearly coordinated, the risk becomes organizational: activities stop while waiting for confirmations, assumptions increase, and the project loses continuity.

Complexity emerges from the interaction between people, processes, and systems.

Many existing systems have grown over time without a coherent vision: successive patches, workarounds, duplications, and layered logic generate technical debt.

Technical debt reduces the ability to change, increases the risk of regressions, and makes every evolution slower and more expensive.

This type of complexity often remains invisible until someone tries to modify the system: a seemingly simple feature may require deep intervention in unexpected areas.

When technical debt is not made explicit, estimates become fragile and the project accumulates friction from the very beginning.

Many software projects assume that existing data is available, coherent, and usable, while data quality and structure are often one of the main sources of uncertainty.

Incomplete databases, inconsistent conventions across systems, duplications, or outdated information can compromise integrations, reporting, and automation.

The risk is designing features that work correctly on paper but are difficult to make work in practice. Software quality depends on the quality of the data flowing through the system.

When this aspect is underestimated, delays, unexpected exceptions, and continuous adjustments emerge during development.

In some projects, the request is clear, but there is no shared vision of the expected outcome. Different stakeholders pursue different priorities: operational efficiency, control, speed, or new business opportunities.

When the objective is not explicitly aligned, software risks becoming the place where existing organizational conflicts emerge.

This generates shifting priorities, conflicting requests, and decisions that continuously change over time because there is no shared definition of what “success” actually means.

Aligning on the problem before the solution reduces ambiguity and allows more coherent technical decisions.