A False Dichotomy

In the world of custom software, many discussions always seem to begin and end in the same way: “Is a fixed-price project better, or Time & Material?”

It is an understandable question. But it is also, almost always, the wrong question.

It is understandable, but it rarely addresses the central issue. The real question concerns who assumes the risk of uncertainty and whether this distribution of risk is coherent with the reality of the project. When this coherence is missing, the project begins to struggle before the first line of code has even been written.

Uncertainty Is a Characteristic of Complex Systems

In many business environments, uncertainty is treated as something that must be eliminated quickly. Requirements are closed as soon as possible, estimates are made more precise than is realistically possible, and roadmaps are built as if the context were stable.

In complex systems, however, uncertainty is structural. A project involving real organizational processes, integrations with legacy systems, critical data, regulatory constraints, and multiple interdependent teams can rarely be fully defined from the start.

When the opposite is assumed, uncertainty does not disappear. It is simply pushed further into the future, where it becomes more expensive, more conflictual, and more difficult to manage.

What Contract Models Actually Do

Every collaboration model does one very simple thing: it decides where risk ends.

In a Time & Material model, the risk of uncertainty largely remains with the client. The supplier provides capacity, not a guaranteed outcome. This model works well when the context is relatively stable, priorities are clear, there is an internal figure capable of making rapid decisions, and the core architecture is already solid. It becomes problematic when it is used to compensate for a lack of strategic clarity. In that case, hours accumulate, but uncertainty is not necessarily reduced.

In a fixed-scope project, by contrast, objectives, budget, and deadlines are defined from the beginning, and risk is formally transferred to the supplier. This works when the scope is genuinely clear, technical constraints are known, and alternative scenarios have already been explored. Tensions emerge when the contract assumes stability in a domain that is not actually stable. Under these conditions, every variation becomes a change request and every decision turns into a negotiation.

When the Chosen Model Does Not Hold

The signals are recurring. Requirements formally considered “closed” but continuously renegotiated. Estimates defended more because of contractual obligations than because of common sense. Constant tension between those who “pay” and those who “deliver.” Change requests perceived as abuse. Endless discussions about what was supposedly “included.”

In these cases, the problem is not technical. It is structural. The chosen model is not coherent with the real level of uncertainty.

A Recurring Example

A company decides to rewrite an internal system that has gradually become critical for operations. Documentation is incomplete, processes have changed multiple times, and some integrations with other systems were created informally.

For reasons related to budget and governance, a fixed-price project is requested. On paper, the system appears well defined; in practice, many business rules only emerge once people attempt to formalize them.

After a few months, the supplier begins defending the original scope while the client discovers functionalities they had taken for granted. The relationship becomes rigid, and every modification turns into a negotiation. The problem originates from treating a high-uncertainty context as if it were stable.

The Most Expensive Mistake

In software projects, the most expensive mistakes are rarely technical. They often originate from the implicit assumption that everything is already clear.

Unspoken assumptions become implicit expectations, and those expectations eventually turn into conflict. No contractual model can compensate for a project built on undeclared assumptions.

Governing Uncertainty

Managing uncertainty does not mean giving up control. It means making uncertainty explicit and proportioning commitment to the level of clarity that has actually been achieved.

In many cases, this means starting with a targeted and time-limited analysis, validating mockups and workflows before full implementation, addressing the riskiest parts first, and keeping the scope flexible while the objective is still not completely defined.

This does not mean “buying time.”

It means avoiding irreversible decisions built on fragile foundations. Every major architectural choice — technology, integration model, service decomposition — is difficult to correct afterward. Reducing uncertainty before making those decisions is an act of responsibility, not excessive caution.

A Matter of Maturity

Addressing uncertainty requires maturity from both sides.

On the client side, it means openly discussing trade-offs, accepting that some decisions cannot be made immediately, and recognizing that certain parts of the system may need to be defined later. On the supplier side, it means avoiding unrealistic promises, clearly distinguishing what is defined from what is not, and adopting a method for progressively reducing risk.

When both sides treat uncertainty as a real variable, the dialogue changes. The discussion is no longer only about costs and deadlines, but also about the main risks, what should be explored first, and where it actually makes sense to commit.

A Risk Allocation Decision

The choice between Time & Material and a fixed-scope project is not an ideological issue. It is a risk allocation decision.

When uncertainty is high, there must be a way to reduce it before making heavy commitments. When the scope is clear and stable, a fixed objective can be efficient. In mature and long-term contexts, a capacity model may make sense.

The point always remains the same: aligning the level of commitment with the level of remaining uncertainty. When this alignment exists, the project has room to work. When it is missing, tensions tend to emerge over time.